Secure virtual community network system

ABSTRACT

A private virtual dynamic network is provided for computing devices coupled to public networks or private networks. This enables computing devices anywhere in the world to join into private enterprise intranets and communicate with each other. In one embodiment, the present invention provides a separate private virtual address realm, seen to each user as a private network, while seamlessly crossing public and private network boundaries. One implementation of the present invention uses an agent to enable an entity to participate in the network without requiring the member to add new hardware or software.

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This Application is related to the following Applications: U.S.patent application Ser. No. 10/233,289, “Accessing An Entity Inside aPrivate Network,” filed on Aug. 30, 2002; U.S. patent application Ser.No. 10/161,573, “Creating A Public Identity For An Entity On A Network,”filed on Jun. 3, 2002; U.S. patent application Ser. No. 10/233,288,“Communicating With An Entity Inside A Private Network Using An ExistingConnection To Initiate Communication,” filed on Aug. 30, 2002; U.S.patent application “Secure Virtual Address Realm,” filed on Mar. 31,2003, Atty. Docket TTCC-01020US0; and U.S. patent application “GroupAgent,” filed on Mar. 31, 2003, Atty. Docket TTCC-01022US0. All theserelated applications are incorporated herein be reference in theirentirety.

BACKGROUND OF THE INVENTION

[0002] 1. Field of the Invention

[0003] The present invention is directed to a network services system.

[0004] 2. Description of the Related Art

[0005] Networked data devices provide users with efficient means forcommunication and collaboration. In recent years, the Internet hasplayed a central role in allowing different types of networked devicesto connect and share information across a myriad of networks. Astechnology advances and more organizations and people rely on theInternet, new challenges are presented for enhancing the ability tocommunicate. One such challenge is to enable the rapid creation of asecure means that allows local and remote specified entities tocommunicate and collaborate from any location via a standard Internetconnection. For any solution to be widely accepted, it must take intoaccount the realities and limitations currently existing.

[0006] For communication on the Internet, the Internet Protocol (IP) hasbecome the default protocol used by most hosts and to whichcommunication applications are now written. To transmit data from asource to a destination, the Internet Protocol uses an IP address. An IPaddress is four bytes long and consists of a network number and a hostnumber. When written out, IP version 4 addresses are specified as fournumbers separated by dots (e.g. 198.68.70.1). Users and softwareapplications do not always refer to hosts or other resources by theirnumerical IP address. Instead of using numbers, they use ASCII stringscalled domain names. The Internet uses a Domain Name System (DNS) toconvert a domain name to an IP address.

[0007] The Internet Protocol has been in use for over two decades. Ithas worked extremely well, as demonstrated by the exponential growth ofthe Internet. Unfortunately, the Internet is rapidly becoming a victimof its own popularity, it is running out of addresses.

[0008] One popular solution to the depleting address problem is NetworkAddress Translation (NAT). This concept includes predefining a number ofnetwork addresses to be private addresses and public addresses. Publicaddresses are unique addresses that should only be used by one entityhaving access to the Internet. That is, no two entities on the Internetshould have the same public address. Private addresses are not uniqueand are typically used for entities not having direct access to theInternet. Private addresses are used in private networks. Privateaddresses can be used by more than one organization or network. NATassumes that all of the machines on a network will not need to accessthe Internet at all times. Therefore, there is no need for each machineto have a public address. A local network can function with a smallnumber of one or more public addresses assigned to a NAT device. Theremainder of the machines on the network will be assigned privateaddresses. Since entities on the network have private addresses, thenetwork is considered to be a private network.

[0009] When a particular machine having a private address on the privatenetwork attempts to initiate a communication to a machine outside of theprivate network (e.g. via the Internet), the NAT device will interceptthe communication, change the source machine's private address to apublic address and set up a table for translation between publicaddresses and private addresses. The table can contain the destinationaddress, port numbers, sequencing information, byte counts and internalflags for each connection associated with a host address. Inboundpackets are compared against entries in the table and permitted throughthe NAT device only if an appropriate connection exists to validatetheir passage. One problem with a many NAT implementations is that itonly works for communication initiated by a host within the privatenetwork to a host on the Internet that has a public IP address. Many NATimplementations will not work if the communication is initiated by ahost outside of the private network and is directed to a host with aprivate address in the private network.

[0010] For most organizations, the security of devices coupled to theInternet is a concern. As a result, not all devices are directlyconnected to or accessible via the Internet. Rather, many devices areplaced in private networks for security concerns (in addition to theaddress usage issue describe above). Many private networks are securedby placing a firewall device between the private network and theInternet.

[0011] Another problem with many current communication schemes is thatmobile computing devices can be moved to new and different networks,including private networks. These mobile computing devices may need tobe reachable so that a host outside of the private network can initiatecommunication with the mobile computing device. However, in this casethe problem is two-fold. First, there is no means for allowing the hostoutside of the private network to initiate communication with the mobilecomputing device. Second, the host outside the private network does notknow the address for the mobile computing device or the network that themobile computing device is currently connected to.

[0012] Thus, there is a need for a system that provides for local andremote entities to communicate and collaborate using the Internet, canwork with existing NAT devices and firewalls, and allows for devices tomove to different physical networks. To increase the ability of such asystem to be accepted by the Internet community, it is desirable forsuch a system to not require changes to existing applications, allowpeer-to-peer applications to communicate directly across the Internetand to not require changes to existing protocols. Each of these issueswill be discussed below.

[0013] Large amounts of resources have been used to purchase and deployexisting applications currently running on the millions of computingdevices. Organizations and individuals are not likely to want to adoptnew communications solutions that require them to absorb the additionalcost of replacing all of their applications.

[0014] To provide efficient and secure communication, it is desirablefor devices to have the ability to allow their IP based applications tocommunicate directly with each other. By allowing peer-to-peerapplications to communicate directly across the Internet, security isenhanced since the recipient is specifically identified andcommunication is passed directly between the applications on two or morerespective machines.

[0015] Most machines on the Internet use the TCP/IP (TransmissionControl Protocol/Internet Protocol) reference model to send data toother machines on the Internet. The TCP/IP reference model includes fourlayers: the physical and data link layer, the network layer, thetransport layer, and the application layer. The physical layer portionof the physical and data link layer is concerned with transmitting rawbits over a communication channel. The data link portion of the Physicaland Data Link layer takes the raw transmission facility and transformsit into a line that appears to be relatively free of transmissionerrors. It accomplishes this task by having the sender break the inputdata up into frames, transmit the frames and process the acknowledgmentframes sent back by the receiver.

[0016] The network layer permits a host to inject packets into a networkand have them travel independently to the destination. On the Internet,the protocol used for the network layer is the Internet Protocol (IP).

[0017] The transport layer is designed to allow peer entities on thesource and destination to carry on a “conversation.” On the Internet,two protocols are used. The first one, the Transmission Control Protocol(TCP), is a reliable connection-oriented protocol that allows a bytestream originating on one machine to be delivered without error toanother machine on the Internet. It fragments the incoming byte streaminto discrete segments and passes each one to the network layer. At thedestination, the receiving TCP process reassembles the received segmentsinto the output stream. TCP also handles flow control to make sure afast sender cannot swamp a slow receiver with more segments than it canhandle. The second protocol used in the transport layer on the Internetis the User Datagram Protocol (UDP), which does not provide the TCPsequencing or flow control. UDP is typically used for one-shot, clientserver type requests-reply queries for applications in which promptdelivery is more important than accurate delivery.

[0018] The transport layer is typically thought of as being above thenetwork layer to indicate that the network layer provides a service tothe transport layer. Similarly, the transport layer is typically thoughtof as being below the application layer to indicate that the transportlayer provides a service to the application layer.

[0019] The application layer contains the high level protocols, forexample, Telnet, File Transfer Protocol (FTP), Electronic Mail—SimpleMail Transfer Protocol (SMTP), and Hypertext Transfer Protocol (HTTP).

[0020]FIG. 1 depicts the basic structure of an IP version 4 packet 10used at the Network Layer. IP packet 10 consists of header 12 andpayload 14. Payload 14 stores the data received from the Transport Layerin the TCP/IP model. FIG. 2 depicts the format of a header of an IPpacket. The header is depicted to include six rows. The first five rowsare 32 bits wide. The first five rows of the header comprise a 20 bytefixed portion of the header. The last row of the header provides avariable sized options field 22. Version field 24 keeps track of whichversion of the protocol the packet belongs to. The current version usedon the Internet is version 4. IHL field 26 describes the length of theheader in 32 bit words. Type field 28 indicates the type of servicerequested. Various combinations of reliability and speed are possible.Length field 30 contains the size of the packet, including both theheader and the data. Identification field 32 is needed to allow thedestination host to determine which packet the received fragment belongsto. All fragments of a packet contain the same identification value.Next comes three flags, which include an unused bit 33 and then two 1bit fields 34 and 36. DF field 34 stands for don=t fragment. It is anorder to the routers not to fragment the packet because the destinationis incapable of putting the pieces back together again. MF field 36stands for more fragments. All fragments except for the last one havethis bit set. Fragment offset field 38 indicates where in the currentsegment this fragment belongs. Time to Live field 40 is used to limitpacket lifetime. It is supposed to count time in seconds, allowing amaximum life time of 255 seconds. In practice, it may count hops (orhops and seconds). The time is decremented on each hop by a router. Whenthe time to live hits 0, the packet is discarded and a warning is sentback to the source using an Internet Control Messaging Protocol (ICMP)packet. This feature prevents packets from wandering around forever.Protocol Field 42 indicates which transport layer type is to receive thesegment. TCP is one possibility, UDP is another. Checksum field 44verifies the header. One method for implementing a checksum is to add upall 16 bit half words constituting the header and take the onescompliment of the result. Note that the checksum must be recomputed ateach hop because the Time to Live field 40 changes or the content of theoptions field changes. Source field 46 indicates the IP address for thesource of the packet and destination field 48 indicates the IP addressfor the destination of the packet. Options field 22 is a variable lengthfield designed to hold other information. Currently, options used on theInternet indicate security, suggested routing path, previous routingpath and time UDP is an alternative to TCP. FIG. 2B depicts thestructure of a packet that uses UDP. Like the TCP, UDP uses the InternetProtocol to actually send a data unit from one computer to another.Unlike TCP, however, UDP does not provide the service of dividing amessage into packets (datagrams) and reassembling it at the other end.Specifically, UDP does not provide sequencing of the packets that thedata arrives in. Hence, application programs using UDP must ensure thatthe entire message has arrived and is in the right order. As shown inFIG. 2B, the packet includes and IP header 12 a and IP payload 14 a. Thepayload 14 a comprises the UDP header 50 and UDP data 60. UDP header 50consists of a 16 bit source port identifier, a 16 bit destination portidentifier, a length field and checksum field. In FIG. 2B, theDestination Port has a meaning within the context of a particularInternet destination address, and the Length field is the length inoctets of this user datagram including its header and the data. Thechecksum is the 16-bit one's complement of the sum of consecutive twooctaves of a pseudo header of information from the IP header, the UDPheader, and the data (padded with zero octets at the end, if necessary,to make a multiple of two octets).

[0021] In addition to using the existing Internet infrastructure,another issue in allowing public-to-private, or private-to-private,communications lies in the addressing of the devices. Where a system iscoupled to the public Internet with an IP address, communication packetscan be routed directly to the machine. However, many devices couple tothe Internet via service providers which provide them with a dynamic IPaddress. Thus, those wishing to communicate with this type of user mustknow the constantly changing address of the user in order to communicatewith them. Still other hosts may be coupled to networks that usetechnologies other than IP.

[0022] One solution currently in use that provides for local and remotespecified entities to communicate and collaborate using the Internet isthe Virtual Private Network (“VPN”). The VPN uses additional networksoftware layers to increase security between users in the public realmand those in private realms. For example, some VPNs encrypt packetsusing IPsec (or other protocols). The encrypted packets are thenencapsulated within a standard packet and transmitted across theInternet to the destination. At the destination, the encrypted packet isdecrypted. While the exiting VPN provides remote users with secureaccess to a network, via the Internet, many existing VPNs have variousshortcomings that prevent them from satisfying the needs of many users.For example, many VPNs do not provide for peer-to-peer communicationwith IPsec (or other security measures), do not work though NAT devicesin all cases, are difficult to set up and maintain, do not provide forfull mobility of entities communicating on the VPN, and do not alwaysprovide for communication with entities in the various private networkconfigurations discussed herein.

[0023] One method of overcoming the mobility problem includes the use ofDynamic DNS. More information about Dynamic DNS can be found in RFC 2136incorporated herein by reference.

[0024] Dynamic DNS is illustrated in FIG. 3. FIG. 3 shows a firstcomputer or device B having a host name of B.COb.com having a dynamic orstatic private IP address IPb and a second computer or device A having ahost name of A.COa.com and having a dynamic or static private IP addressIPa. Devices B and A are coupled to the Internet 506 via firewalldevices 302, 304 incorporating NAT. The addresses of B and A, as seen bydevices on the Internet, are public IP addresses GIPb and GIPa,respectively. Also shown is device D, having a publicly address IPd anda host name of d.COd.com.

[0025] Also shown is a Dynamic DNS server, DDNS, residing on theInternet. In essence, the DDNS server is a DNS server supporting thedynamic DNS protocol of RFC 2136, and in this example is anauthoritative name server containing records for B, A and D. The DDNSserver will update it's records of B, A and D in real time, so that ifor when D's address IPd changes, any query by other devices (B, A, forexample) based on D's host name, will result in the response being thecorrect IP-IPd. Any DNS records for devices B and A will always reflectthe public IP addresses (GIPa and GIPb) of the firewall/NAT devices.

[0026] Unfortunately, DDNS technology is complex and difficult toimplement securely—two factors that have dramatically slowed the rate ofdeployment of Dynamic DNS. As a result, VPNs have not been able to adoptDDNS to solve all of the problems discussed herein.

[0027] Hence, a system is desired that allows local and remote entitiesto communicate and collaborate from any location via a standard Internetconnection and which solves the problems discussed above.

SUMMARY OF THE INVENTION

[0028] A system is disclosed that desired that allows local and remoteentities to communicate and collaborate from various locations. In oneembodiment, the system makes use of a virtual subnet with a virtualaddress realm. The virtual address realm allows two or more users tocommunicate securely via at least one public network, whether the usersare both coupled directly to the public network, both coupled directlyto separate private networks or whether one is in a public network andone is in a private network. The virtual address realm uses virtualaddresses to identify the devices on the virtual subnet. Although thedevices are in different physical subnets, from the point of view of theapplications the devices of the virtual subnet appear to be in one localsubnet.

[0029] In one embodiment, the virtual address realm comprises a virtualaddress realm definition including at least a set of users. Each useraccessing the virtual address realm may have at least one virtualaddress in the virtual address realm and at least one physical address.

[0030] Another embodiment of the present invention comprises a virtualcommunity network for transmitting communications via at least onephysical network. The virtual community network comprises a virtualaddress realm including a logical name assignment, a set of userscapable of communicating in the virtual address realm, and a securecommunication channel. In a further aspect, the virtual communitynetwork logical name is a domain name, and the domain name may be afully qualified domain name or a virtual domain name. In another aspect,the set of users includes at least a first user coupled to a firstprivate physical network and a second user coupled to a second privatephysical network, and the first private physical network and the secondprivate physical network may have at least one common private physicalsubnet address. The physical addresses may be dynamic or static.

[0031] Yet another embodiment of the invention is a method comprisingthe steps of: defining a virtual address realm overlying a publicaddress realm, the virtual address realm including at least a user setand a logical name for said user set; and routing communications betweenusers in the user set by means of virtual address realm addresses. In afurther aspect, this method includes the step of registering users inthe user set as members of the virtual address realm. Further, themethod may include the step assigning each registered user a uniquevirtual address in the virtual address realm. The method may furtherinclude the steps of encrypting communications between devices in therealm, and/or applying at least one address realm group policy.

[0032] A further embodiment of the invention is a method for providingsecure communications between two devices. The method comprises thesteps of: providing a virtual realm identifier; defining a set of usersfor the virtual realm; registering users in the realm; assigning virtualaddresses; and routing information between users in said virtual addressrealm.

[0033] A still further embodiment of the invention comprises one or moreprocessor readable storage devices having processor readable codeembodied on said processor readable storage devices. In this embodiment,said processor readable code is for programming one or more processorsto perform a method comprising the steps of: providing a virtual addressrealm configuration including a user set and a domain name for said userset; and routing communications between users in said virtual addressrealm.

[0034] Another embodiment of the invention comprises a method forproviding a secure virtual network. The method may include the steps of:providing a virtual network manager coupled to a public network;defining a member set of users entitled to communicated in the virtualnetwork; registering members with the manager; assigning members avirtual address; and routing network traffic between the members in thevirtual community.

[0035] An additional further embodiment of the invention may compriseone or more processor readable storage devices having processor readablecode embodied on said processor readable storage devices. The processorreadable code may be for programming one or more processors to perform amethod comprising the steps of: managing a virtual community networkrealm; defining a member set of users entitled to communicated in thevirtual community; registering users with the virtual community;assigning each user a virtual address; and routing network trafficbetween the users in the virtual community.

[0036] Another embodiment of the invention is a virtual communitynetwork system. The system includes a virtual network manager includingat least one virtual community definition comprising at least a domainname and a user set; and at least one route director capable ofcommunicating with users in the user set.

[0037] In a further aspect, the virtual community network includes acommunication agent installed on a device. The agent may comprise avirtual network adapter interfacing with the device and applications onthe device to route traffic to members of the virtual community viatheir virtual address.

[0038] For some devices, additional software or hardware cannot beinstalled on a member device or it is not desirable to install suchadditional software or hardware on the device. For such devices, a GroupAgent can be used. The Group Agent acts as a proxy for one or moremembers of a virtual community without requiring installation of memberagent software on the client devices.

[0039] One embodiment of a system that uses a Group Agent includescommunicating with a first client and acting as an intermediary betweenthe first client and members in a first virtual address realm so thatthe first client can communicate in the first virtual address realm.Note that in this embodiment the first client is not configured tocommunicate in the first virtual address realm. For example, no softwareis installed on the client to add drivers, layers or interfaces specificto the first virtual address realm.

[0040] Another embodiment of a system using a Group Agent includescommunicating messages with a first client and communicating themessages with members in a virtual address realm on behalf of the firstclient. While communicating with the first client, the messages do notuse virtual addresses. During the communication process, the messagesare transformed so that the messages include virtual addresses whencommunicating with members in the virtual address realm and the messagesdo not include virtual addresses when communicating with the firstclient.

[0041] In one implementation, the first entity resides in a firstphysical address realm and the second entity resides in a secondphysical address realm, where the first physical address realm overlapswith the second physical address realm. For example, consider thesituation where the first physical address realm is a first privatenetwork using a first set of private addresses and the second physicaladdress realm is a second private network using a second set of privateaddresses, where there are private addresses that exist in both thefirst set of private addresses and the second set of private addresses.

[0042] The present invention can be accomplished using hardware,software, or a combination of both hardware and software. The softwareused for the present invention is stored on one or more processorreadable storage media including hard disk drives, CD-ROMs, DVDs,optical disks, floppy disks, tape drives, RAM, ROM or other suitablestorage devices. In alternative embodiments, some or all of the softwarecan be replaced by dedicated hardware including custom integratedcircuits, gate arrays, FPGAs, PLDs, and special purpose computers. Inone embodiment, software implementing the present invention is used toprogram one or more processors. The processors can be in communicationwith one or more storage devices, peripherals and/or one or morecommunication interfaces.

[0043] These and other objects and advantages of the present inventionwill appear more clearly from the following description in which thepreferred embodiment of the invention has been set forth in conjunctionwith the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0044] The invention will be described with respect to the particularembodiments thereof. Other objects, features, and advantages of theinvention will become apparent with reference to the specification anddrawings in which:

[0045]FIG. 1 depicts an IP packet.

[0046]FIG. 2A depicts the format of a header of an IP packet.

[0047]FIG. 2B depicts the format of a UDP packet.

[0048]FIG. 3 depicts a print-out implementation of a dynamic routingsystem.

[0049]FIG. 4 depicts a block diagram of an implementation of the systemof the present invention.

[0050]FIG. 5A is a structural network block diagram illustratingelements used in the system of the present invention.

[0051]FIG. 5B is a logical block diagram depicting communication typesin an implementation of the system of the present invention

[0052]FIG. 6A depicts a packet structure for a communication packet inaccordance with the present invention.

[0053]FIG. 6B is a table depicting the shim configuration of the packetin FIG. 6.

[0054]FIG. 7 is a flow chart describing the overall process forcommunicating.

[0055]FIG. 8 is a block diagram illustrating the structure of the MemberAgent application in the system of the present invention.

[0056]FIG. 9 is a flowchart illustrating the steps which occur in thecreation of a virtual community.

[0057]FIG. 10 is a flowchart illustrating the process of configuring avirtual community.

[0058]FIG. 11 depicts an HTTP wrapper structure.

[0059]FIG. 12A is a flow diagram depicting a user registration processof the present invention.

[0060]FIG. 12B is a table illustrating the structure of the registrationfile information structure.

[0061]FIG. 13 is a flowchart depicting a member join process inaccordance with the present invention.

[0062]FIG. 14 is a flowchart depicting a member leave request inaccordance with the present invention.

[0063]FIG. 15 is a flow diagram depicting DNS request for a member inthe virtual community in accordance with the present invention.

[0064]FIG. 16A depicts the commonly used IKE phase one aggressive modeexchange.

[0065]FIG. 16B depicts the IKE phase one aggressive mode exchange usedin accordance with the present invention.

[0066]FIG. 17 depicts a packet structure of the virtual IKE phase 1packet.

[0067]FIG. 18 depicts the IKE ticket payload data structure.

[0068]FIG. 19 is a representation of a system ping sequence inaccordance with the present invention.

[0069]FIG. 20 is a flow diagram depicting a query request in the systemof the present invention.

[0070]FIG. 21 depicts a flow structure for addressing and routingconducted by a Route director.

[0071]FIG. 22 is a block diagram depicting one embodiment of variouscomponents of the present invention utilizing a Group Agent.

[0072]FIG. 23 is a flow chart describing one embodiment of the processfor Group Agent initialization.

[0073]FIG. 24 is a flow chart describing one embodiment of a process forinitiating communication with a member that is using a Group Agent.

[0074]FIG. 25 is a flow chart describing one embodiment of a process forcommunicating using a Group Agent.

[0075]FIG. 26 is a flow chart describing one embodiment of a process forinitiating communication by a member that is using a Group Agent.

DETAILED DESCRIPTION

[0076] One embodiment of the present invention provides for a secureVirtual Community Network or “VCN.” In essence, a VCN is a privatedynamic network which acts as a private LAN for computing devicescoupled to public networks or private networks. This enables computingdevices anywhere in the world to join into private enterprise intranetsand communicate with each other. Thus, the invention provides a separateprivate virtual address realm, seen to each user as a private networkwhile seamlessly crossing public and private network boundaries.

[0077] A basic overview of the system is shown in FIG. 4. FIG. 4 shows acomputer or device B (host name—b.COb.com) in a first private domain andcomputer or device A (host name—a.COa.com) in a second private domain,both of which are coupled to the Internet by firewall devices 402, 404.The firewall devices are configured to implement Network AddressTranslation (NAT). A and B have dynamic or static private IP addresses.Computer or device X is coupled directly to the public Internet and hasa public IP address.

[0078] In the present invention, a virtual community network (VCN) X.VCNis formed. Machines A, B and X can join the VCN, leave the VCN, or allowother machines in the VCN to communicate with them. More than simply avirtual private network (VPN), all members of the VCN are accessible asif they were part of a physical local network. The application runningon the members of the VCN can accomplish what they would be able toaccomplish if they were on the same physical routed network (e.g. all inthe same private network). Membership in the VCN is controlled by anadministrator via an administrative interface. In general, theadministrator defines certain aspects of the VCN and then invitesmembers into the VCN by specifying the domain name for each member.Members then register themselves with a VCN Manager, and notify theManager via join and leave requests when they are available toparticipate in the community. Once registered and joined, members cancommunicate with other members as though connected via a local LAN.

[0079] As shown in FIG. 4, A, B and X may all make direct connections toeach other through communications within the virtual domain. In FIG. 4,dashed lines represent direct communication paths seen to applicationsrunning on A, B and X, all “seeing” the virtual addresses of each otherand communicating with each other using the application's IP interface.

[0080] A hardware architecture for the machines, server or other devicesused to implement the present invention should be well understood to oneof average skill in the art. Suitable hardware includes one or moreprocessors, a memory, a mass storage device, a portable storage device,a first network interface, a second network interface and I/O devices,in communication with each other. The choice of processor is notcritical as long as a suitable processor with sufficient speed ischosen. The memory can be any conventional computer memory. The massstorage device can include a hard drive, CD-ROM or any other massstorage device. The portable storage can include a floppy disk drive orother portable storage device. If the computer is acting as a router, itincludes two or more network interfaces. In other embodiments, thecomputer may include only one network interface. The network interfacecan include a network card for connecting to an Ethernet or other typeof LAN. In addition, one or more of the network interfaces can includeor be connected to a firewall. For a gateway, one of the networkinterfaces will typically be connected to the Internet and the othernetwork interface will typically be connected to a LAN. However, agateway can exist physically inside a network. I/O devices can includeone or more of the following: keyboard, mouse, monitor, display, printeretc. Software used to perform the methods of the present invention arelikely to be stored in mass storage (or any form of non-volatilememory), a portable storage media (e.g. floppy disk or tape) and/or, atsome point, in memory. The above described hardware architecture is justone suitable example depicted in a generalized and simplified form. Thepresent invention could include dedicated hardware, a dedicated routerwith software to implement the invention or other software and/orhardware architectures that are suitable.

[0081] A more detailed overview of one embodiment of the presentinvention is depicted in FIGS. 5A and 5B. FIG. 5A illustrates variousembodiments of devices coupled to public and private networks in amanner which allows use of the present invention, and is arepresentation of a physical connection of such devices. FIG. 5Billustrates a logical representation of elements used to create a VCNand of the various formats of communication traffic between thoseelements shown in FIG. 5A.

[0082] Specifically, FIGS. 5A and 5B illustrate various user machinesM_(n) coupled to the Internet 506, as well as other devices, describedbelow, which implement a virtual community in accordance with thepresent invention. Devices M_(n) can be personal computers, servers orother computing devices (mobile or non-mobile). Each machine may havedifferent communication connectivity with the Internet.

[0083] In general, an exemplary system for implementing a VCN inaccordance with the invention comprises a VCN Manager 510, a NetworkRoute Director 520 and/or Private Route Director 530, and a number ofMember Agents 565. Communication between systems in various protocols isillustrated by dashed lines (UDP) and solid lines (TCP). The VCN managerand Network Route Director are shown in FIG. 5A as being coupleddirectly to Internet 506.

[0084] User devices M_(A) and M_(E) are connected to the Internet andhave public IP addresses. These addresses may be dynamic or static. Ifstatic, M_(A) and M_(E) can easily communicate with each other in amanner well known in the art by simply addressing IP packets directly toeach other. If the addresses are dynamic, then M_(A) and M_(E) requiresome means of knowing when the IP address of the other changes in orderto communicate. As described below, the VCN system provides such ameans.

[0085] Device M_(B) is in a private domain (e.g. private network)) 540and connected to a NAT Device 530 to access the Internet 506 by aprivate network path 540 a. Device M_(B) may use have a dynamic orstatic IP address specific to the private domain 540. Generally, suchaddresses are part of the private received IP classes which are notroutable via the Internet. For example, 10.0.0.0-10.255.255.255,172.16.0.0-172.31.255.255, 192.168.0.0-192.168.255.255 are networkaddresses classified for private networks. Firewall/NATdevice 515translates Machine M_(B)'s private IP address to a routable public IPaddress. NAT device 515 may include other security functions as well.M_(B) communicates with other non-VCN devices on the Internet via theNAT device 515, and with other members of the VCN via Private RouteDirector (PRD) 530, which is coupled to the private network path 540 aand is a member of the private network 540. Device M_(X) is also shownas connected to and a member of the private domain 540 but has a static,routable public IP addresses. As such it may communicate with devicescoupled to Internet 506 in a different manner, as illustrated in FIG.5B.

[0086] Devices M_(C) and M_(D) are part of a second private domain (e.g.private network) 550 coupled to a second private network path 550 a.Again, these machines have static or dynamic private IP addresses andare coupled to the Internet via a firewall/NAT device 517, which isitself coupled to network path 550 a.

[0087] The VCN Manager 510 is a central server or server clusterproviding management services, connection services and security servicesfor the VCN. Each Member Agent 565 includes client agent software (or,in some embodiments, hardware) that runs on end machines and providesvirtual network services. It enables the machine to be reached frompublic and private networks, and implements the security aspects of thesystem. In FIG. 5B, machines M_(A), M_(B), M_(C), M_(D), M_(E) and M_(X)all include Member Agents and, therefore, can be members of a particularVCN.

[0088] The Network Route Director (NRD) 520 is a stand-alone unit thatruns on the public side of the Internet enabling Member Agents and GroupAgents (discussed below) to be reached inside one or more privatenetworks from the public network. Private Route Director (“PRD”) 530 isan element that runs inside a private network enabling access tomachines inside the private network from machines outside the privatenetwork. It can run as a service on a platform offering other servicessuch as a Windows Server.

[0089] Generally, VCNs are defined and managed by the VCN Manager 510.Clients utilize Member Agents or Group Agents to access other clientmachines (M_(n)), in private or public realms. The NRD or PRD routescommunications to Member Agents.

[0090] As described herein, three forms of communication are used increating and implementing the VCN. TCP is used in the registration andjoining processes; encapsulated UCP packets are used between elements inestablishing communication between joined devices and for managementtraffic, and Encrypted UCP packets are used for agent-to-agentcommunications.

[0091]FIG. 5B shows exemplary traffic between elements of the VCN. Afirst type of traffic is TCP traffic. TCP traffic is used between memberagents to establish membership in the VCN (the registration process),and make the VCN manager aware they are available to communicate withother members of the VCN (the join process). In FIG. 5B, this isrepresented by solid lines 513 b, 511 b, 523 b and 543 b. TCP is alsoused: by the PRD 530 to establish communications with the VCN (lines 527b, 527 d); and by the member agent of device M_(B) to communicate withthe PRD 530 (line 533 b). TCP may also be used by devices M_(C) andM_(D) on private network 550 to communicate with each other.

[0092] Encapsulated UDP traffic is used by elements of the VCN oncemembership has been established and the elements are joined in the VCNfor management and administrative communications. This is represented inFIG. 5B by lines 511 a, 513 a, 523 a, 527 a, 527 c, 523 c, 527 e, 521,543 a, 541, and 519. Encrypted UDP communications are used betweendevices, shown in FIG. 5B between device M_(X) and M_(A) at 525 anddevice M_(B) and M_(C) at 537.

[0093] In one embodiment, secure connections are built dynamically usingIPsec tunnels based on a virtual IP space that can traverse from privatenetworks, across the Internet and into other private networks. Strongauthentication and the establishment of IPsec policies at the timemembers join the community offers privacy and security to the members ofthe virtual community. This facilitates the introduction of a variety ofpolicy-based network services with centralized management such asVirtual Private Networks for intranets and extranets, IP-telephonydomains, and IP-based PDA communities.

[0094] Communications Protocol

[0095] In the present invention, an encapsulation routing protocolallows packets to traverse addressing boundaries and identifies routingendpoints by unique DNS domain names. It employs an addressvirtualization scheme that accomplishes backwards compatibility withIPv4 applications. With certain optional exceptions, UDP encapsulationis used between elements of the Virtual Community.

[0096] One example of an encapsulated packet 600 is depicted in FIG. 6A.It includes a 20 octet IP header 602, an 8 octet UDP header 604, a 20octet system shim 606, and a variable size virtual IP packet 608. Avirtual IP packet has the same format as a standard IP packet.

[0097] Members of a VCN communicate to other members of that VCN bymeans of virtual IP Packets 608. Virtual IP addressing is used toestablish unique connection identities for community connected devices.IPsec can (optionally) be applied to the Virtual IP Packet forend-to-end security. Virtual IP addresses are used to identify membersin the community in the virtual packet and are not directly routable.Rather, they are unique identifiers of a given connection to the upperlayer application. In one embodiment, virtual IP addresses are in IPV4format.

[0098] In general, the UDP header is set for a default port. System shim606 carries enough addressing information to allow the Route Directorsto forward the tunneled packet through the various address realms on itsway to the destination. Such a routing methodology is often referred toas source routing.

[0099] In order to route packets to a peer in a different addressingrealm, the protocol stack knows the address of the appropriate RouteDirector that serves the peer's realm, the private address of the peeror a NAT address. The Member Agent obtains the information by using theVCN Manager as a DNS authority for DNS lookup operations as describedbelow (FIGS. 13 and 21). The DNS response from the VCN Manager willinclude the above-identified information in an optional text field ofthe response to the Member Agent.

[0100] TCP/IP connections require IP addresses to be used as connectionidentifiers at the user level. If an application wishes to make aconnection to “m3.abcdef.com” and another to “m4.abcdef.com”, itresolves both DNS identifiers into IPv4 addresses. The system cannotassign the private IP addresses of the members to be unique connectionidentifiers, because two members might have the same private address indifferent private address realms.

[0101] Assigning a virtual address to each peer designated by a DNSstring solves the problem of ambiguous endpoints. These virtualaddresses may be any legal IPv4 addresses, but conflicts will occur ifthe same addresses are used to directly designate a peer in an IPv4network application. For instance, if 10.0.0.10 is used as a virtualaddress, and is also used on a member's network as the mail server,packets that are ordinarily destined to the mail server may beredirected to a random peer. In general, when choosing virtual addressesit is best to choose addresses that will not be routable to the member.Hence, each member is assigned a virtual IP address unique in thecontext of the virtual community and that will not conflict with anylocal addresses on its LAN or any public IP addresses on the Internet.

[0102] By having each member of a VCN use a virtual address, a virtualaddress realm is created. The virtual address realm is the set ofaddresses that can be used to identify and send communications to othermembers of the VCN. The virtual address realm is different from aphysical address realm because the physical address realm is actuallyused to route on a physical network. The members of a VCN will all be inthe virtual address ream of that VCN, but may be in different physicaladdress realms. For example, looking at FIGS. 5A and 5B, M_(B) and M_(C)are in different physical address realms (e.g. 540 and 550); however,they are both in the virtual address realm of the VCN. Another examplecan be seen with FIG. 4, where A and B are in different physical addressrealms (Cob.com and Coa.com); however, they are both in the same virtualaddress realm. Applications on members of a VCN will see the VCN as thelocal subnet; therefore, the VCN can be thought of as a virtual subnet.Each member of the VCN will appear to the application as an entityconnected to the local subnet.

[0103] Route Directors 530 and 520 facilitate routing UDP encapsulatedtraffic to private address domains 540, 550. In general, Route Directorseither have public IP addresses or addresses that are staticallyremapped to a public IP address. The static translation of a RouteDirector's IP must leave the port in the UDP header unchanged to allowthe UDP encapsulated destination port number to be directly used bypublic members, by other Route Directors, and by private members. RouteDirectors 520, 530 and VCN Manager 510 may be configured to use anon-default UDP encapsulation port. In one embodiment, all outgoingmessages are sent to this port on the next destination node and allincoming messages are read from this port. As discussed below,information in a “join” packet tells Member Agents the UDP encapsulationport to use in communications to Route Directors, network managers, andother members of the community.

[0104] System Shim 606 (see FIG. 6A) has a format given by way ofexample in FIG. 6B. Protocol Version information, data type, headeroption flags, and Router Information are potentially stored in the Shim.(The abbreviation “gIP” stands for “global” or public IP address,indicating an Internet routable IP address). The Data Type fieldindicates the meaning of the optional data that may follow the Shim.This may include a Virtual IP Packet 608, a ping to a Route Director, arequest for a Network Route Director virtual address, a Route Directorresponse with a virtual address, a member leaving and releasing avirtual address, and a member-to-Route Director packet. The shim alsoincludes the public IP address for the source machine's Route Director,the public IP address for the destination machine's Route Director, theprivate IP address for the source machine and the private IP address forthe destination machine. In the case where the source or destination usea public IP address, then the shim will not need to include the privateaddresses of the source/destination or a route director.

[0105] The system can optionally use TCP encapsulation between a memberand a Route Director. If the VCN Manager determines that a Member Agent(e.g., Agent software on a member machine) and a Route Director are bothable to support a TCP connection, then it may instruct the member toinitiate a TCP connection with the Route Director. TCP port 80 may beused as the destination port for all TCP encapsulated messages to theRoute Director, and TCP port 20202 may be used as the source port forall TCP encapsulated messages from a private member to the RouteDirector.

[0106] As noted above, Network Route Directors (NRDs) 520 facilitaterouting traffic into and out of private address domains withoutrequiring reconfiguration of a firewall 517 protecting the domain 550.As in UDP encapsulation, a special field in the system join packet(explained below) tells the Member Agent which TCP encapsulation port touse as the source port. The NRD will then re-encapsulate virtual-trafficin UDP-encapsulation before passing it on to other elements of thevirtual network.

[0107] Note that more than one user can use the same device, with eachsuch user having different virtual addresses in the same or differentaddress realms. Additionally, regardless of the number of users, onedevice can be in multiple virtual address realms. In some embodiments, auser can have multiple identities, each in a different address realm.

[0108]FIG. 7 is a flow chart describing the overall process forcommunicating between members of a VCN. Any member of a VCN cancommunicate with any other member of a VCN regardless of whether eitherof the members are behind a firewall, behind a NAT device, directlyaccessible via the public Internet, in a private network, etc. From thepoint of view of an application on a member device, all the othermembers appear to be on the same LAN. Thus all applications running on amember's device will think that all other members of the VCN are on thesame LAN and in the same address realm (e.g. the virtual address realmof the VCN).

[0109] In step 650 of FIG. 7, the Agent for the potential member joinsthe VCN and receives a virtual IP address. In order to establish orparticipate in communication within the VCN, a device must register withand join the VCN, thereby becoming a member of the VCN. The Agent willsend a message to VCN Manager 510 and receive a virtual IP address back.The virtual IP address received is used to identify the member in theVCN. More details of step 650 as well as other portions of FIG. 7 willbe discussed below. Note that there is a dotted line between step 650and step 652. This dotted line signifies that a lot of time can passbetween step 650 and step 652. Additionally, after step 650 isperformed, it does not need to be repeated.

[0110] In step 652 of FIG. 7, an application on the source machine (themember initiating communication) intends to send a message to anapplication on the destination machine (another member of the VCN).Examples of applications that can communicate on the VCN include instantmessaging, email, FTP, browsers, data transfer programs, and otherapplications that can communicate. Consider an example when applicationon device M_(A) intends to initiate communication with an application ondevice M_(B). Thus, M_(A) is the source device and M_(B) is thedestination device. In step 654, the application on M_(A) will initiatea DNS request using the domain name for M_(B). This DNS request is sentto VCN Manager 510. In step 656, VCN Manager 510 returns the publicaddress of the Route Director for the destination, the private addressfor the destination device and a virtual IP address for the destinationdevice. In the example described above, step 656 includes returning thepublic IP address for private Route Director 530, the private addressfor M_(B) and a virtual IP address for M_(B). If the destination machinehas a public IP address (and, thus, does not use a routing director)then step 656 will only include returning the public IP address for thedestination. If the destination machine is in a private network thatuses a Network Route Director (e.g., NRD 520), then step 656 will returnthe public IP address for the Network Route Director.

[0111] In step 658, the Agent for the source device, which received theinformation in step 656, will store that received information. Thisinformation can be stored in a table, or any other data structure. Instep 660, the Agent for the source device will return the virtual IPaddress of the destination device to the application on the sourcedevice. In step 662, the application on the source device will initiatethe sending of a message/data using the virtual IP address for thedestination device. In step 664, a virtual IP packet will be created.The source IP address for the virtual IP packet will be the virtual IPaddress for the source device. The destination IP address for thevirtual packet will be the virtual IP address for the destinationdevice. The virtual IP packet will be in the same format as a standardIP packet. In step 664, the newly created virtual IP packet will besubjected to IPsec (or another security means). In some embodiments,IPsec is not used. In step 670, the virtual IP packet is encapsulated.For example, in one embodiment, the virtual IP packet is encapsulated asdescribed above with respect to FIGS. 6A and 6B. This encapsulation willinclude shim 630. As described above, shim 630 will include the publicIP addresses for the Route Directors for the source and destination, andthe private IP addresses for the source and destination devices. Ifeither the source or destination do not have a Route Director, the shimwill not need to include that information. For example, when the sourcemachine is M_(A), there is no Route Director for the source. If thesource machine was M_(C), then the shim would include the public IPaddress for Network Route Director 520. If the source is M_(B), the shimwould include the public IP address for Private Route Director 530.

[0112] At this point, the path of the packet will depend on whether thedestination is using a Private Route Director 530, Network RouteDirector 520 or has a public IP address. If the destination has a publicIP address, the process moves to step 678 where the encapsulated packetis forwarded to the destination agent.

[0113] If the destination is in a private network that has a PRD, thenin step 672 the encapsulated packet is sent to the NAT device for thedestination. For example, the encapsulated packet is sent from M_(A) toNAT 515. In step 674, the encapsulated packet is sent from the NATdevice for the LAN that includes the destination to the Route Directorfor the destination. For example, the encapsulated packet is sent fromNAT 515 to private Route Director 530. In step 676, the Route Directorwhich received the encapsulated packet will remove the virtual IP packetand the shim from the encapsulation. The Route Director will read theshim to learn the local IP address to send the packet to. The shim andvirtual IP address will then be re-encapsulated into a new packet withthe original virtual packet. The new outer packet includes a destinationIP address equal to the private IP address of the destination device.The encapsulated packet received in step 674 will include a source IPaddress equal to the public IP address for M_(A) (or the source's RouteDirector) and a destination IP address equal to the public IP addressfor the Route Director of the destination (e.g., PRD 530). In step 678,the new encapsulated packet will be sent from the Route Director to theAgent for the destination device.

[0114] If the destination agent is in a private network and is using aNetwork Route Director, then following encapsulation the encapsulatedpacket is sent to the Network Route Director for the destination agentin step 673. At step 675, the NRD will remove the virtual IP Packet andshim and re-encapsulate them in a UDP packet for transmission through aNAT device to the destination via a persistent UDP connection betweenthe NRD and the destination. At step 677, the encapsulated packet isforwarded to the NAT device (via the persistent UDP connection) behindwhich the destination Agent resides, which will perform its own routingof the encapsulated packet to the destination Agent in step 678.

[0115] In step 680, the Agent will remove the shim and the virtual IPpacket from the encapsulation. The virtual IP packet will be removedfrom IPsec (e.g. decrypted). In step 682, the information from the shimwill be stored by the Agent. In step 684, the contents of the virtualpacket will be presented to the application on the destination device.That is, the application on the destination device will receive thecontents of the data payload, or at least a portion of the data payload

[0116] When the destination wishes to respond to the source or thesource wishes to send additional information, the process of FIG. 7 canbe repeated. However, when repeating the process of FIG. 7 between twomachines where communication is already established, the steps ofperforming the DNS request do not need to be performed again. That is,when the destination wishes to respond, the destination will perform thesteps in FIG. 7 starting at step 662. The Agent for the destinationdevice will already know all the information to put in the shim.Additionally, when the source device wishes to send additionalinformation to the destination device, the source device can start FIG.7 at step 662. In some embodiments, however, the steps of performing theDNS request will be performed again.

[0117] Member Agent

[0118] As noted above, devices in the VCN utilize a member agentinstalled on the device to communicate. One unique aspect of the systemof the present invention is the integration of the agent software in atypical device.

[0119]FIG. 8 illustrates the functional flow diagram of an installedagent on a device such as a computer, server or other device. Region 810illustrates the “user space,” and region 820 represents the kernel areaof the components interacting with the host device.

[0120] Applications 830 interact directly with an IP stack 835 which isbuilt on a deterministic network extender or DNE 850. The deterministicnetwork extender is provided by Deterministic Networks, Inc. The networkextender allows one to implement any driver level functions such asIPsec, browsers, traffic redirectors, and the like, through a series ofplug-ins. As shown in FIG. 8, a number of plug-ins, including a DNSplug-in 852, an IPsec plug-in 854, a virtual adapter manager 856 and adomain name router 858 (see U.S. Pat. No. 6,119,171, incorporated hereinby reference) interact with the deterministic network extender 850. TheDNS plug-in processes DNS queries by applications via the stack. Thevirtual adapter manager allows for additional adapters to co-exist inthe same device.

[0121] The DNE is an NDIS compliant module (in Windows environments)which appears as a network device spire to the protocol stack 835. TheDNE supports the TCP/IP and UDP protocols and various adaptor types. Inessence, this forms a virtual network adaptor in device installations.This means that various configurations for each virtual community can beprovided for each DNE. This provides the advantage that a number ofmembers or users can utilize the same device, with the device installinga different virtual adaptor using plug-ins for the deterministic networkenhancer and each user does not need to reconfigure the network settingsof the machine to join each community. Each plug-in is constructed inaccordance with standards promulgated by the DNE provider.

[0122] As shown in FIG. 8, user applications interact directly with theIP stack of the virtual adapter. Each adapter provides its own stack tothe device's applications. To the applications, each stack appearsseparate, and no separate routing of the application is required. Forexample, the IKE user application 825 can interact with the domain nameplug-in, the IPsec plug-in, the virtual area management communicator856, and the security policy manager 860. The Adapter Manager 856 allowsparallel stacks for each VCN to be implemented and used on each machine.This means a user and device can belong to several VCNs without needingto re-configure IP settings to access each VCN.

[0123] VCN Definition

[0124]FIG. 9 shows the steps which occur at the VCN Manager to defineand establish a virtual community. At step 902, an administrator sets upa virtual community by providing information to the VCN Manager via auser interface (not shown). It will be understood that the userinterface and the method of providing information to the VCN Manager isnot critical to the system of the present invention. One particularlyadvantageous interface is implemented in a World Wide Web browser. Theinterface may be implemented using HTML, XML, Java Applets, Java Server,Active Server Pager or any of a number of well-known Web technologies.The particular information required to set up the community network isillustrated in FIG. 10. Next, at step 904, users who are designated bythe administrator as being allowed access to the virtual communitydefined in step 902 are notified by any number of appropriate means. Inone implementation, the users are notified by e-mail, although otherforms of notification, such as verbal or personal notification, may beused. The e-mail may contain an invitation to join the community,community authentication information, a link to a location to downloadthe Member Agent, and/or a link to the Group Agent. Next, at step 906,using information contained in the e-mail, users register with the VCNManager. Registration in this context means registering a machine usinga Member Agent or a Group Agent with the VCN Manager. Users may berequired to install the Member Agent software. The link in thenotification e-mail may provide the user with a location for downloadingthe Member Agent software as well as instructions for installing thesoftware. Other information, such as system password information, isprovided in the e-mail. Finally, at step 908, management of thecommunity is handled by the VCN Manager. This includes monitoring whichregistered users have joined and left the system, answering DNSrequests, and applying security policies, as described herein. This mayinclude notifying new users and registering those users as thedefinition of the VCN changes.

[0125]FIG. 10 is a flowchart illustrating the process of setting up avirtual community which is performed by an Administrator. Initially, theAdministrator sets up a virtual domain name and address domain at step1002. This information is used by the VCN Manager and Route Directors toallow members to communicate. Next, users are defined at step 1004. Inone embodiment, the users are defined by providing the domain names ofeach of the users who will be invited to participate in the VCN. At step1006, default passwords are set. This is the password a user first usesto access the system. The user may be forced to change the password forsecurity reasons at a later date. Finally, at step 1008, polices may bedefined at the domain level, the user level, or for individual machinesin the domain. Policies are used to allow or deny access to individualmachines, services, or other users.

[0126] Member Registration

[0127] The registration process is the first step that a user andmachine go through with the VCN Manager before becoming a member of avirtual community. There are two phases to member registration: aregistration request and a registration file request. Registrationhappens outside of the IPsec tunnels because at registration time noIPsec tunnel exists for the user registering.

[0128] In one implementation, all traffic between Member Agents and theVCN Manager (with the exception of Registration and Join functiontraffic is encapsulated using UDP encapsulation, represented by lines511 a, 513 a, 523 a, 519, 521, 527 a, 527 c, 537, 523 c, 527 e, 541, 543a, 533 a of FIG. 5B). This encapsulated traffic will carry managementtraffic between the members and the VCN Manager. A service port isreserved at the VCN Manager in the virtual network for the establishmentof a TCP connection between a member and the VCN Manager. A member thatjoins a VCN is informed of the service port as part of the joinprotocol. A DNS port is also open on the virtual side of the VCNManager. In one embodiment, the VCN Manager virtual ports are TCP Port9001 and DNS UDP Port 53. The packets used for the initial Registrationand the subsequent Join operations use TCP port 80 outside the virtualnetwork. This is represented in FIG. 5 by the solid lines 513 b, 511 b,523 b and 543 b.

[0129] VCN system protocol packets that are sent outside the systemtunneling are HTTP wrapped and sent to the VCN Manager on TCP port 80 tofacilitate NAT traversal. More information about NAT traversal will beprovided below. Each packet includes a header and payload. Forcompatibility with firewalls, the HTTP wrapper makes the packet aSOAP-compatible XML document. Including a binary data portion after XMLis consistent with Direct Internet Message Encapsulation (DIME), aproposed lightweight, binary message format that can be used toencapsulate one or more application-defined payloads of arbitrary typeand size into a single message construct.

[0130] The format of the HTTP wrapper from the Member Agent to the VCNManager is shown in FIG. 11. The wrapper includes an HTTP HEADER, XMLHEADER and P-LENGTH fields. The HTTP header includes a POST HTTP field,an Identity field, a Content Type field, and a Content Length field. TheXML header includes version information and packet type information. TheHeader includes error codes and explanations, as well as the contenttype and length.

[0131] The Registration exchange between the member agent and the VCNManager is shown in FIG. 12A. When a Member Agent 565 attempts toregister at step 1200, Member Agent 565 will send a registration requestpacket 1202 to the VCN Manager 510 to start registration. The packet isincluded in an HTTP wrapper as illustrated at 1204. The registrationpacket will carry the client Fully Qualified Domain Name (FQDN) and aDiffe-Hellman Key Exchange request to the VCN Manager. The packetfurther includes packet version information, type and lengthinformation, a user authenticator, the length of FQDN in octets, a VCNname offset, the member's FQDN in DNS format, the length ofDiffe-Hellman value in octets, and the member's initial Diffe-Hellmanvalue.

[0132] An Initial Password is passed to the user through an outsidechannel, such as e-mail (or other channel). In a setting where securityis a concern, an alternative method such as personal communication orencrypted e-mail may be used.

[0133] The registration authenticator is computed using the firstsixteen bytes of the HMAC-SHA-1 applied to the packet data with thepassword hash as the key. (Normally, the HMAC-SHA-1 algorithm generatesa 20-byte result; in one embodiment of the system only the first(leftmost) 16 octets are used in the MAC.) The formulas are as follows:

HMAC-Key-Field=SHA-1(Initial Password)

Authenticator=HMAC-SHA-1₁₆(HMAC-Key-Field, Data)

[0134] The VCN Manager will respond in one of three ways 1206, 1208,1212, to the registration packet 1202. VCN Manager 510 will acknowledge(ACK) the packet at step 1212 with the Registration Acknowledge (ACK)packet 1214 if the member belongs to a community but its status is “notregistered.” The VCN Manager also sends a phase-2 confirmation code tothe member's e-mail address and changes the member status to“registering.” The packet will transfer a “Time To Live” value to themember which is a timeout period in seconds for hearing back from themember with the confirmation code. Phase two of registration must becompleted in this time period.

[0135] If the packet is abnormal (in size, FQDN length, bad type, etc.),the authenticator check fails, the member does not exist in thedatabase, or the VCN server is not running, the VCN Manager drops thepacket in step 1206. The packet will be not-acknowledged (NACK) 1210 ifthe member is already in the “registered” state, the send e-mailoperation fails, the process of updating the member to the “registering”state fails, or the random generator fails in attempting to generate aconfirmation code in step 208.

[0136] Upon receiving the Registration ACK 1214, the user will sendRegistration File Request Packet 1220 to the VCN Manager 510 to startregistration. This packet will transfer the following information to theVCN Manager: a registration file User Authenticator, the length of FQDNin octets, a VCN name Offset, and the member's FQDN in DNS format.

[0137] The registration file user Authenticator contained in the FileRequest packet 1220 is slightly different from the Registration RequestAuthenticator in packet 1202, in that the Initial Password, passed tothe user through an outside channel (e-mail for example), and theConfirmation Code, a temporary code sent in the second e-mail with atimeout to the user, are used:

HMAC-Key-Field=SHA-1(Initial Password)

User Authenticator=HMAC-SHA-116(HMAC-Key-Field, SHA-1(ConfirmationCode)+Data)

[0138] The VCN Manager will send a Registration File acknowledge Packet1230 to the member 565 in response to the Registration File Requestpacket 1220 in step 1228 if it is determined that the member belongs toa community. The Acknowledge Packet 1230 will transfer the followinginformation to the member:

[0139] Crypto Type—a code indicating how the rest of the packet isencrypted. This is provided in a crypto type field preceding theregistration file.

[0140] Registration File—a structure with a number of fields containingthe information required by the member to successfully perform a join.It is sent encrypted using the key generated via the Diffie-Hellman keyexchange.

[0141] A table representing the Registration File structure is shown inFIG. 12B. As shown therein, the Registration File contains anAuthentication Type, a File Type, a File Length definition, a Token Key,a Key Timestamp, a Key Type, a Key Length, a High Availability (HA)Version, a HA Number, Server Information and Padding. The Token key isthe shared secret with the server. The Token Key is identified by theKey Type, which is normally a Diffie-Hellman type in one embodiment. TheVCN Manager also changes the member status to “registered.”If at step1224, the member agent status is not set at “registering,” or thetimeout for phase 2 has expired, a NACK packet 1226 is sent. If thepacket is abnormal (in size, FQDN length, bad type, etc.), theauthenticator check fails, or the user does not exist in the database,or the VCN server is not running, the packet is dropped in step 1222.While current encrypting method for the file is to generate a key/IVpair from the combined Diffie-Hellman value using a Key DerivationFunction, any number of suitable substitutes may be used.

[0142] In addition to the registration authentication described above,the system uses a packet authenticator to verify communications betweenthe VCN Manager and Agents. The Authenticator is a cryptographicallystrong hash of the packet keyed by a shared secret between the sourceand destination. The authenticator is calculated over the entire packetusing the HMAC-SHA-1 algorithm. The inputs to this Authenticator are notavailable until after Registration. As illustrated above, duringregistration an Authenticator based on the user password is used. Thefields used in the calculation are a Diffie-Hellman Key comprising amulti-octet random string that is the result of the Diffie-Hellman keyexchange protocol, and the entire packet data, with the Authenticationfield zeroed out.

[0143] The Authorization Key, AuthKey, described above, is derived fromDiffie-Hellman using the KDF2 function, and used for general packetAuthentication. AuthKey=KDF2 (Diffie-HellmanKey)MAC=HMAC-SHA-116(AuthKey, Data). The AuthKey need be calculated onlyonce per registration from the KDF2 of the DH key and then stored forlater use. It is known as the Authentication key and is 20 octets long.

[0144] Member Join/Leave

[0145] Once a user is registered, the user can join the VCN. Oncejoined, the user is a member of the VCN. Joining allows the user to letthe VCN Manager and other members know that the user/member is on-lineand available to communicate. The Join protocol runs between a MemberAgent and the VCN Manager to establish a session key with the Manager,authenticate to the Manager, and make use of connections via the RouteDirectors in the community.

[0146] The Member Join process is illustrated in FIG. 13. There are twophases to the Join operation: phase one is an Initialize Request andphase two is the actual Join. At join time, the IPSec tunnel for securecommunication is not established, so the first few join packets are sentoutside the IPSec tunnel.

[0147] Initially, at 1302, the Member Agent 565 will send an InitRequest Packet 1304 to the VCN Manager 510 to start authentication. Thepacket will carry the following information to the VCN Manager:

[0148] Version Variant Mask—used to indicate optional variations of theprotocol from the member to the VCN;

[0149] Token Timestamp—identifying when a Token Key was created (inseconds);

[0150] Member seed—a random number to thwart so called“man-in-the-middle” attacks;

[0151] Member Local IP—the member's Local LAN IP address; and

[0152] Client FQDN—the client's fully qualified domain name.

[0153] Again, three responses 1306, 1308, 1312 are possible. At step1306, if the packet is abnormal, it will be dropped. Similarly, if themember fails authentication, at step 1308 a NACK packet 1310 will besent.

[0154] If the member passes authentication at 1312, the Manager willsend an acknowledgement packet 1314 to Member 565. An AuthKey is alsotransmitted as part of the INIT Request Packet, and the Managerauthenticates the packet by checking this against a secure key digest.The acknowledgement packet 1314 packet will transfer the followinginformation to the member:

[0155] Version Variant Mask—version information;

[0156] Member Seed—from the Init Request to protect against playbackattacks;

[0157] Manager Seed—a unique seed used to thwart man in the middleattacks;

[0158] Session AH Key—used in IPsec;

[0159] Session ESP Key—used in IPsec;

[0160] Init ACK Time—a time stamp used to tie this packet to thefollowing Join Request. There is a timeout if the Join is delayed toolong;

[0161] Authentication Method—the method used for authentication;

[0162] Route Director Private IP—if member is in a private network, thisis the private IP address of the Private Route Director. The value iszero if no Route Director is used;

[0163] Route Public Public IP—if member is in a private network, this isthe public IP address of the Private Route Director. The value is zeroif no Route Director is used;

[0164] Tunneling Port—used for UDP encapsulation Route Director Flags.Only Bits 0 and 1 currently used to direct the agent to a Private RouteDirector, Network Route Director with UDP, or a Network Route Directorwith TCP.

[0165] At step 1312 of the join process, the VCN Manager will alsodetermine whether the Member Agent attempting to join is behind a NATdevice. The method by which this occurs is discussed below with respectto FIG. 21 and the results of this determination may force the Agent tonegotiate a session with a Network Route Director which will provide apseudo address value used as the Agent's local IP value in the Joinrequest, discussed below. This process is discussed in depth withrespect to FIG. 21.

[0166] Following receipt of the acknowledgement packet, at step 1316,the member will send Join Request Packet 1318. The packet's payloadincludes a manager seed, the initial ACK time, join flags, the membermachine's local IP address (or pseudo address), the Route Director'sprivate IP address, the Route Director's public IP, the member AH SPIand ESP SPI, the member listen port, a token timestamp, a GUIDidentifying the current client run, NetBIOS name support, a passwordhash, version information for high availability and security policyinformation.

[0167] In step 1320, the VCN Manager will drop this packet if it isabnormal. In step 1322, the VCN Manager will send a NACK packet 1324 ifthe member is not in the registered state, the timeout for Join fromINIT ACK has expired, or updating the member to the Joined state fails.

[0168] If the join action succeeds, then in step 1326 the VCN Managerwill send an acknowledge packet 1328. The acknowledge packet payloadincludes the RMI Port at the VCN Manager, the Tunneling Port, VCNManager Authentication Header (AH), Security Parameters Index (SPI) forIPsec, VCN Manager Encapsulating Security Payload (ESP) SPI for IPsec,the UTC Time (in seconds) when the member joined, VCN Manager Heartbeatinterval (in seconds), the Member Heartbeat interval (in seconds), theVCN Manager's Virtual IP address, the Manager Subnet Prefix Length, theVCN Member Subnet Prefix Length, the Route Director's private IPaddress, the Route Director's public IP address, an indication of theupdates that follow, an update of the Token Key, an update of theSecurity Policies, an update of High Availability indication, andpadding. The member has now joined the community at 1330. Once themember has joined, all communications can be encrypted using IPsec.

[0169] The system of the present invention also includes RADIUSauthentication support. Generally, if a member attempts to authenticateusing a RADIUS server, the VCN Manager will perform the same steps aswhen it receives the Join Request packet except for having a RADIUSserver authenticate the member. The payload for this packet is similarto the Join Request packet except that it has an additional field forRADIUS password that is used by the RADIUS server to authenticate themember.

[0170]FIG. 14 shows the sequence for leaving a VCN. Initially, at step1410 when a Member Agent is prepared to leave the community, a LeaveRequest Packet 1412 will be sent to the VCN Manager 510 to start theleave process. The Leave Request Packet will carry a Leave Flag, theFQDN Length, FQDN VCN Offset and Member FQDN. Unless dropped at step1414 or a problem exists at 1416 which would generate a NACK packet1418, the VCN Manager will send the Leave ACK Packet 1430 to the memberin step 1420. This packet has no payload. At step 1440, the member hassuccessfully left the community.

[0171] DNS/Lookups

[0172] For one member to communicate with another member, the initiatingmember's agent will perform a query or DNS lookup (step 654 in FIG. 7)to determine the address of the other member, and then establish asecure communication channel between them.

[0173] The Member Agent utilizes the VCN Manager to perform lookups ofother virtual members in the virtual community using DNS. The DNSoperation is conducted using the DNS protocol with the VCN Manager. Themember software sends a DNS query to the VCN Manager, and the managerreturns information about the target member. Besides the target member'svirtual IP address, the DNS response also contains additionalinformation about the target member. While the VCN Manager accepts allDNS requests, it will only acknowledge the DNS requests of type A, whichare targeted to virtual domain names in the secure virtual communitiesof the VCN Manager. The VCN Manager is the authoritative name server forthose virtual domain names; other requests will simply be responded towith a “Server Failure.”

[0174] The DNS query and response sequence is illustrated in FIG. 15. Atstep 1510, a member will request a DNS lookup by sending a DNS request1520 to port 53 of the VCN Manager. The DNS request 1520 will result ina normal DNS response 1575 unless any of a number of failure conditionsare met, shown at steps 1522, 1540, 1550, and 1560.

[0175] If the Manager receives a query on port 53 that is not a DNSquery, then at step 1522, it is dropped. If, at step 1524, the query isnot a standard query, such as a DNS STATUS (a status lookup) or IQUERY(inverse DNS), or the class of the DNS query indicates an Internet (IN)query, or if the TYPE value of the request is a pointer (PTR) or hostaddress (A), then, a “Not implemented” DNS response 1530 is sent overthe virtual link to the Member Agent 565.

[0176] At step 1540, the VCN checks to see if the source IP address isfor a member of the VCN. If the source IP address is not for a member ofthe VCN, the virtual IP look up fails or the type PTR query does notmatch, a “server failed” response 1545 is returned. At step 1550, ifthere is no DNS Question section or there is another type of formaterror with the packet, a “format error” response 1555 is sent. The VCNdetermines whether the member has joined the VCN, at step 1560. If not,a name error response is sent at 1565.

[0177] If the name is a successful lookup (step 1570), then the VCNManager will send a DNS Response Packet 1575 to the member 565. Theresponse includes the following information: the target member FQDN; thetarget member virtual IP address; a source Route Director flag, thesource member virtual IP address; the target member join time; thetarget member agent version; the target member private IP address; thetarget Route Director public IP address; the target member NetBIOS name;the shared key, shared by the two members; a target Ticket length; atarget member Ticket encrypted for target member only and containing aTicket issue time, Ticket expiration time, and shared key; the targetmember virtual IP address, the source member virtual IP address, thesource member private IP address; the source Route Director public IPaddress, the source member FQDN; and padding (to obtain a multiple of 16octets). The Ticket provided by the DNS request is detailed further inthe description of FIG. 16B.

[0178] The target member's virtual IP address will be presented using anA-type resource record in the answer section of the normal DNS responsepacket. All the remaining information will be transferred using aTXT-type resource record in an additional section of the DNS Response.

[0179] Encapsulation

[0180] Traffic between Member Agents in the VCN is encapsulated usingUDP encapsulation. Encapsulated traffic between members can carry any IPtraffic from any standard IPv4 compliant application. However, one portis set aside in the virtual network at the application layer toestablish a connection between two members in the community. In oneembodiment, this is UDP port 500, which is set aside for Internet KeyExchange (IKE), allowing negotiation of an IPsec tunnel between the twomembers.

[0181] When an application on a member device wishes to open aconnection to a peer on a target member device, a protocol is followedfor the establishment of the IPsec session between the two. MemberAgents are configured to listen on the UDP tunneling port (whichdefaults to port 20202) for virtual traffic. As an accepted procedurenon-IPsec traffic on the virtual IKE port 500 is accepted and passed toan IKE and Security Policy Module to allow for the possibility ofinitiating an IKE exchange and the establishment of an IPsec sessionbetween the two members.

[0182] IKE is fully described in RFC-2409. IKE provides a key exchangewith a peer and creates a security association (SA) for the IPsecmodule. IKE access between peers occurs in two phases: phase 1establishes a secure, authenticated, channel with which to communicate,and phase 2, which negotiates a Security Association on behalf of IPsec.Phase 1 is generally referred to as the ISAKMP Security Association (SA)and includes a “Main Mode” and “Aggressive Mode.” In one implementation,Aggressive Mode is used for phase 1. One of the allowed phase 2exchanges is “Quick Mode” and in one implementation, Quick Mode is usedin the system for phase 2.

[0183]FIG. 16B shows the aggressive mode IKE phase one exchange utilizedin the present invention. FIG. 16A shows the standard aggressive modeIKE phase one exchange for comparison. In these figures, in accordancewith standard IKE parlance, one device is considered an exchange“initiator” and the other a “responder”.

[0184] In general, in phase one of the IKE exchange, peers areauthenticated, an IKE Security Association (SA) policy between peers isestablished, a Diffie-Hellman exchange is performed to produce matchingshared secret keys and a secure tunnel to negotiate IKE phase twoparameters is established.

[0185] In FIG. 16A, an initiator exchanges a header (HDR), SAnegotiation payload, Key Exchange (KE), nonce payload (Ni, where “i”indicates an “initiator” payload) and identity of the party (IDii). Thekey exchange payload contains the public information exchanged in aDiffie-Hellman exchange. The responder returns the HDR, SA, KE, aresponder nonce payload (Nr), its identity (IDir) and the HASH responder(HASH_R) payload, which is generally a hash of the ID payload and isused to authenticate the exchange. The initiator returns the HDR andHASH initiator (HASH_I) payload, and the initial secure tunnel isestablished.

[0186] In accordance with the present invention, FIG. 16B illustratesthe use of an extension to aggressive mode exchange. This is performedby adding a ticket payload (TKT*) to distribute a shared-key to remotepeers.

[0187] The Ticket is the means by which one Agent can identify whetheranother Agent is a trusted member of the virtual community. Essentially,the Ticket includes information identifying the initiating member to thereceiving member.

[0188] The ticket is issued by the VCN Manager and encrypted for thereceiving member with a member-server shared secret; only the receivingmember can open it. The ticket contains a time-stamp, a sequence numberand a shared-secret used for IPSEC between the two members. Tocommunicate with the receiving member, the initiating member obtains theticket from the VCN Manager (through, for example, the DNS sequence,described above) and passes it to the receiving member in a payload thatcan ride on an IKE packet. The receiving member receives the Ticket,decrypts the Ticket using the member-server shared secret, and uses theinformation in the Ticket to establish secure communication with theinitiating member.

[0189] This payload, TKT, is formatted as shown in FIG. 17. The packet1700 contains an IP header 1710, UDP header 1720, System shim 1730, andVirtual IKE Phase 1 UDP/IP packet 1740. FIG. 18 illustrates thestructure and data of an exemplary first packet 1740. The IKE TicketPayload in the first IKE packet contains information on the payload andthe payload data, including the type of payload following next and theticket payload data 1756. The payload data 1750 includes the size,number and item list 1766. The item list 1760 includes type, size anditem information. The IKE ticket payload data 1740 contains the itemtypes The item types 1770 are shown in the last table of FIG. 18: “MyFQDN”—a null terminated FQDN in label dot format. (For example, a humanreadable FQDN “bob.system.com” is encoded as “bob.system.com\0×00.”) MyTicket data which includes a Manager Current Time (UTC of Manager asknown by initiator); and an Initiator Virtual IP (Obtained at Join time)Target Virtual IP (Obtained from Manager) and Padding. The Peer FQDNFormat is a null terminated FQDN in label dot format. For example, ahuman readable FQDN “bob.system.com” is encoded as“bob.system.com\0×00”. Finally, the Peer Ticket data includes: a TicketIssue Time (UTC (seconds) on VCN Manager); a Ticket Expiration (UTC(seconds) for ticket expiration); a Shared Key used by the two Membersfor IKE; a Target Virtual IP Address; the Initiator NAT Port; theInitiator Subnet; the Initiator Virtual IP Address; Initiator Private IPAddress, the Initiator Public IP Address, the Initiator FQDN andpadding.

[0190] The Diffie-Hellman key exchange protocol is utilized in theInternet Key Exchange (IKE) protocol that precedes IPsec. The prime andgenerator value are taken from a well-known Internet Draft entitled,“More Diffie-Hellman groups for IKE,” Kivinen et al., IP SecurityProtocol Working Group (IPSE) Internal Draft, Dec. 13, 2001, forproposed use within the Internet Key Exchange (IKE) protocol.

[0191] Administrative Functions

[0192] The system can simulate pings to any of the Route Directors (NRDor PRD). This ping is sent inside a packet generated from an applicationused to trouble-shoot the virtual network by touching the RouteDirectors and insuring that they are alive.

[0193] An exemplary ping process is illustrated in FIG. 19. As showntherein a pinging application 1902 at step 1904 sends a ping requestpacket 1906 to the Route Director 560. The Route Director receives theping at 1910 and generates a response at step 1912. The ping responsepacket 1914 is returned to the application 902 at step 1916.

[0194] The ping request packet is sent and returned on the defaulttunneling UDP port (which in FIG. 5B is UDP Port 20202). The PingRequest 1906 packet is formatted as shown in FIG. 19, with the contentof the shim and the ping packets exploded in further detail. In the shim1930, the source and destination Route Director public IP addresses(gIP) and private IP addresses (pIP) are all set to 0. In the systemping field 1960, the ping type field may be a ping request or a pingresponse. The Sequence field in the response is set to the same value asthe Sequence field in the request packet.

[0195] Another function which may be performed is an Agent Query. FIG.20 illustrates a query request from a Member Agent requiringsystem/status information of another member. The first Member Agent 565at step 1802 will send a Query Request Packet 1810 to the VCN Manager510. The Packet contains definitions for the Maximum Number of Recordsto return, a status Mask indicating whether the members are registeredand/or joined, a platform Mask, indicating the platform (desktop,server, laptop, mail server, etc) of the member, the FQDN Length, FQDNVCN Offset, Search String Length, Member FQDN and a Search String forpattern matching. This packet is sent over the IPsec tunnel between theVCN Manager and the Member Agent.

[0196] If the packet is abnormal it is dropped at step 2012 if there isan error in the query authentication file or the member is not joined,NACK 2016 is sent in step 2014. If the packet is not abnormal, no erroris present, the member passes authentication and was joined, then theVCN Manager sends a query acknowledgement Packet 2030 to the member. Thepacket payload includes a number of records with the following fields:the status of the member, the platform type of the member, and themember's FQDN String. Note that the FQDN is null-terminated andconsistent with the FQDN in DNS format definitions. Here, a humanreadable FQDN “www.abcdefg.com” is encoded as “www.abcdefg.com\0×00”.

[0197] Each joined member will periodically send a heartbeat packet tothe VCN Manager so that the VCN Manager can determine if the member isalive. In addition, the member's heartbeat packet is used to determinehow long the member is actually joined. This information can be used toallow a provider of the infrastructure for the system to generaterevenue from users on a per-use time basis. Conversely, the VCN Managerperiodically sends its heartbeat packet to joined members so that thejoined members can know if the Manager is alive. This can be used by themember to determine if it should switch to a backup VCN Manager.Heartbeat packets are sent inside the system tunnel on the defaulttunneling port (UDP port 20202) and are IPsec protected.

[0198] Route Directors

[0199] Route directors allow communication to a member that is in aprivate network. The PRD resides within a private network, behind theNAT device. The NRD resides on the public side of the NAT device. TheNAT device can be a Network Address Port Translation (NAPT) NAT deviceor a basic NAT where only addresses are translated.

[0200] Note that devices with public addresses do not require RouteDirectors (RDs). In the context of FIG. 5B, devices M_(A) and M_(E) donot require either a PRD or NRD, since they reside in the public addressspace. Likewise, M_(X) does not require the PRD for its domain 540,since it has a public address (or is statically mapped to a publicaddress at the NAT device 515).

[0201] The NRD implements a NAT traversal architecture which allowsSystem packets to enter and exit a private network. The NRD maintainspersistent connections/sessions with members that are behind NATdevices. Member Agents initiate a TCP or UDP persistentconnection/session with the NRD and use keep-alive messages to ensurethat the NAT device does not drop the member's connection/session. Theuse of TCP or UDP is based on a bit set by the VCN Manager in the INITACK packet of the Join Protocol. Communication to a member using a NRDtunnels between the NRD and the Member Agent through the persistentconnection/session. More information about a suitable NAT traversalarchitecture is found in U.S. patent application Ser. No. 10/233,289,“Accessing an Entity Inside a Private Network,: and Ser. No. 10/233,288,“Communicating With An Entity Inside a Private Network Using an ExistingConnection to Initiate Communication,” both of which are incorporatedherein by reference.

[0202] When a member behind NAT attempts to join a virtual network bycontacting the VCN Manager as discussed above, the VCN Manager willdetect the presence of the NAT device, direct the member to a specificNRD and indicate the use of TCP or UDP. The presence of the NAT devicemust be detected during the initialize Init message portion of the joinsequence so the VCN Manager can inform the member that it needs to setupa session with the assigned NRD prior to the Join message sequence.

[0203] In one embodiment, the NRD uses a pseudo address. The pseudoaddress is different than the virtual address and is used solely for NRDrouting. The pseudo address assigned by the NRD will allow the NRD tomap a packet to the member's post-NAT IP address and UDP port.

[0204] The process for establishing a session with a NRD and obtainingan address therefrom is shown in FIG. 21. Initially (as described inFIG. 13), a member behind a firewall will send an init request 1304 toVCN Manager 510. In addition to the functions performed with respect tostep 1306, 1308, and 1311 (of FIG. 13), the VCN Manager will detect thatthe member is behind a NAT device and whether it is served by a PRD instep 2120.

[0205] The detection of a NAT device is accomplished using a field withthe member's local IP address in the Init packet sent to the VCNManager. The VCN Manager detects the fact that Agent 565 is behind a NATdevice by comparing the member's private IP address in the INIT messagepayload with the source address in the TCP/IP headers. If the addressesdiffer, then a NAT device is present. At step 2120, the VCN Manager mustnext check if the member's NAT device is associated with a known PRD(Premises Route Director). If no PRD is found, then the VCN Manager willcheck if the member can use a known NRD. If an NRD is found then theINIT ACK 1314′ will indicate that the member must establish a sessionwith the NRD prior to joining the VCN. If the NRD can support TCPtunneling, the INIT ACK will also indicate to the member to start a TCPconnection rather than a UDP connection. If neither a PRD nor an NRD isfound for the private member, an Init NACK will be returned. The VCNManager will find an available NRD and send an INIT ACK 1314′ with theNRD info data contained therein. The contents of an INIT ACK packet 1314are discussed above with respect to FIG. 13.

[0206] At step 2132, the member will seek to establish a session withthe NRD and will send address request 2130 to the NRD. The member sendsthe Address Request Packet 2130 to the NRD. The packet includes an IPHeader, UDP Header or TCP header, and Shim. In this case, the shimincludes the NRD's public address. At step 2135, the NRD assigns themember a pseudo address. This is used as the member's private address inthe Shim when external members send packets to the NRD for forwarding tothe private member. The NRD will store the association of the pseudoaddress with the Member's NAT device public address and port number.When other members of the VCN perform a DNS request on the member behindthe NRD, as part of the DNS response, they will receive the publicaddress of the NRD and they will receive the pseudo address as theprivate address for the member behind the NRD. When sending acommunication to the member behind the NRD, the outer packet will beaddressed to the public address of the NRD. The NRD will access the shimto identify the pseudo address. The NRD uses the pseudo address as ahandle to the persistent connection/session when sending packets througha NAT to the member. Once identifying the appropriate persistentconnection/session, the shim and virtual packet are encapsulated andsent to the destination, via the NAT device, using the identifiedpersistent connection/session. When the NAT device receives the message,it will do the address and port translation, and forward the message tothe member agent's real local address and port on the private network.

[0207] In one aspect, the pseudo address comprises portions of thepublic IP address space in IP version 4 that had been reserved forspecial purposes. This ensures that no machine within a private realmwill have the same pseudo IP address as the private address of a machinein any separate and distinct private realm. In order to prevent thisfrom happening, the system of the present invention uses addresses thatare otherwise not used or reserved. Examples include the 0.0.0.0, the10.0.0.0, 14.0.0.0, 127.0.0.0, 169.2454.0.0, 172.16.0.0 and the like.

[0208] The NRD provides the pseudo address to the Agent 565 in a NATTraversal Address Response Packet 2140. The packet includes a shimhaving an indicator that the response is a pseudo address response, aswell as the source Route Director public IP address and DestinationRoute Director public IP address, (which is set equal to the NRDaddress), the Source member private IP address (0) and the Destinationmember private IP address, which is the Virtual IP. Hence allcommunications for the Member Agent will be routed to the NRD 520. Afteracquiring the pseudo address from the NRD, the member designates thatpseudo address to the VCN Manager as its local address in Join packet1318.

[0209] Note that there is an extra packet exchange 2145, 2150 whenestablishing a TCP connection that is not required when establishing aUDP connection with the NRD. This packet is the NRD Init Request Packet2145. The previous TCP session for the Address Request and AddressResponse must be closed and a new TCP session opened which will remainopen for the duration of the tunnel session. The member sends the InitRequest message to the NRD as the first message in this TCP session.This message only has a TCP header and System Shim preamble, and has nodata following the Shim.

[0210] After receiving the pseudo address, the join process completeswith the join request packet 1318, and join ack packets 1328. After thejoin processing is complete, TCP/UDP encapsulated traffic flows betweenthe member and the NRD through the NAT. The member is now ready toestablish connections with other members.

[0211] When outbound System traffic from a member behind a NAT device tothe NRD is not frequent enough to keep the NAT device's mappings active,the member may to send keep alive messages to the NRD's TCP port 80 orUDP encapsulation port to ensure that the NAT device does not drop theTCP/UDP encapsulation session. The member sends this message to the NRDto ensure that the NAT device does not drop the TCP/UDP port mapping.The keep-alive messages do not need to be sent when other messages weresent out during the keep-alive interval.

[0212] The member sends this NAT Traversal Leave Packet message to theNRD to release the session and pseudo address when the member is leavingthe VCN. The NAT traversal switch will verify that the receive-fromsocket address this message came from matches the lookup table entrybefore deleting the member's address.

[0213] Group Agent

[0214] For some devices, member client software cannot be installed onthe device or it is not desirable to install member client software onthe device. For example, a printer or other networked devices may not beable to load software. For various reasons, some entities may not desireto add network software onto their machines. Additionally, some devicesmay use operating systems that do not support running the member agentsoftware. For those devices that cannot or choose not to use memberagent software, a Group Agent can be used. The Group Agent acts as aproxy for one or more members of a VCN without requiring installation ofmember agent software on the client devices. Thus, a device can become amember of a VCN without changing any of the software on the device byusing the Group Agent.

[0215]FIG. 22 is a block diagram depicting various components of thepresent invention utilizing a Group Agent. Note that some of the membersof a VCN can use a Group Agent while other members do not use a GroupAgent. FIG. 22 shows ten devices M₁-M₁₀. Devices M₁, M₂, M₃, M₄ and M₁₀are devices that are participating in the VCN without using member agentsoftware. Rather, they will use a Group Agent. Devices M₅, M₆, M₇, M₈and M₉ are devices which include member agent software and, therefore,do not need to use a Group Agent. FIG. 22 shows some of the manyvarieties of permutations of using Group Agents, Network Route Directorsand Private Route Directors. Other permutations can also be used withthe present invention. Also note that FIG. 22 is more of a structuralview of additional components of the present invention, as compared toFIG. 5B which is more of a symbolic/logical view.

[0216]FIG. 22 includes a first private network which connects to theInternet (or other network) via NAT device 2202. In addition to NAT2202, the private network includes device M_(1,), device M₂ and GroupAgent 2204. In one embodiment, the Group Agent runs on the same machineas a Private Route Director. Devices M₁ and M₂ do not include agentsoftware. Rather, they participate in the VCN using Group Agent 2204.

[0217] A second private network allows devices to communicate to theInternet (or other network) via NAT device 2210. That private networkalso includes Group Agent 2212, device M₃ and device M₄. Note that GroupAgent 2212 does not include a Private Route Director. Thus, for devicesM₃ and M₄ to be reached by other members of the VCN, communication isperformed via Network Route Director 520. In one embodiment, each of theprivate networks are different physical address realms. That is eachuses a different set of private IP addresses. The present invention willalso work if the private networks have overlapping addresses. That is,one or more private IP addresses are used by more than one privatenetwork involved in a VCN.

[0218] A third private network, which includes devices M₅ and M₆,provides for communication on the Internet via NAT device 2220. A fourthprivate network, which includes devices M₇ and M₈, allows its componentsto communicate on the Internet (or other network) via NAT device 2230.This fourth private network includes Private Route Director 2232.Because devices M₇ and M₈ include member agent software, there is noneed for a Group Agent on this network. Device M₉ has a public IPaddress and includes member agent software; therefore, it communicatesand participates in the VCN as described above. Device M₁₀ has a publicIP address; however, device M₁₀ does not include member agent software.For device M₁₀ to participate in the VCN, it must make use of GroupAgent 2234, which has a public IP address.

[0219] In one embodiment, a Group Agent includes software running on acomputing device, including (but not limited to) a server, router,personal computer, minicomputer, mainframe, mobile computing device, orother suitable computing device. In other embodiments, the Group Agent,or any other of the software components described above, can beperformed by its special purpose computing device.

[0220] A Group Agent acts as a proxy for one or more members which donot have member agent software. For example, Group Agent 2204 is a proxyfor devices M₁ and M₂; and Group Agent 2212 is a proxy for devices M₃and M₄. Group Agent 2234 is a proxy for device M₁₀. Although FIG. 22shows the Group Agents being proxies for one or two members, a GroupAgent can be a proxy for more than two members.

[0221] Communication between two members of a VCN can pass through twoNAT devices, one NAT device for each member. For example, communicationbetween device M₁ and device M₄ will pass through NAT device 2202 andNAT device 2210. Additionally, communication between device Ml andanother entity in a private network configured like the private networkof device M₁ will require communication to pass through two NAT devices.

[0222] Note that a single Group Agent can participate in more than oneVCN. For example, Group Agent 2204 can be used to allow device M₁participate in a first VCN and concurrently (for all or part of thetime) allow device M₂ to participate in a second VCN. Because there canbe multiple virtual community networks, the VCN Manager is able tocreate and maintain, the multiple virtual community networks. Asdescribed herein, the VCN Manager identifies which entities cancommunicate on each VCN by maintaining a list of domain names for eachVCN. For example, one list may include the domain names for devicesM₁-M₁₀.

[0223] The Group Agent requires initialization so it may know whichmembers it is a proxy for. Group Agent initialization cannot occur untilafter the Group Agent has joined the VCN Manager as a member. The joinprior to Group Agent initialization is for a pseudo-member so the proxyinitialization messages can use virtual IP addresses and the tunnelingprotocols described above to travel on an IPsec tunnel between VCNManager 510 and the particular Group Agent. Separate member specifictunnels will be created when the Group Agent later joins for the proxiedmembers. The Group Agent join will require the Group Agent to beregistered with the VCN Manager. In one embodiment, this registrationwill be done during the installation of the Group Agent.

[0224]FIG. 23 provides a flowchart describing one embodiment of theprocess for Group Agent initialization. In step 2302, the Group Agentjoins as a pseudo-member. This process of step 2302 is performed asdescribed above. In step 2304, the Group Agent will send aninitialization request to the VCN Manager. The initialization request isa packet that includes the fully qualified domain name for the GroupAgent, a packet version indication, a packet type indicating that it isan initialization request, a packet length, and an authentication code.If the received initialization request is abnormal (step 2306), then theinitialization request is dropped in step 2308. If the packet was normalbut authentication failed (step 2312), then the VCN Manager sends a NACKto the Group Agent in step 2314. If authentication was successful andthe initialization request was normal, then the VCN Manager sends anacknowledgement to the Group Agent in step 2320.

[0225] After completion of step 2320, the Group Agent is initialized andnow must join each of the members it is proxying. To do so, the GroupAgent will perform a loop where each iteration will include joining forone of the members that is being proxied. In step 2322, it is determinedwhether there are any more members being proxied that have to be joined.If there are more members to join, then the Group Agent will join forone member being proxied in step 2324 and the method will loop back tostep 2322. When there are no more proxied members to be joined, theprocess of FIG. 23 is complete (step 2330). The process of joining for aproxy member is the same as the process of joining described above;however, the process is performed for the member by the Group Agentrather than by the member agent. The virtual IP address received by theGroup Agent is for the member being proxied. The Group Agent stores thatvirtual IP address in a data structure for the member. In oneembodiment, there is a separate data structure for each member beingproxied. In another embodiment, there is one data structure which hasseparate records for each member being proxied. This data stored willinclude the member's virtual IP address and private address in the localLAN, as well as other information that will be described below.

[0226] The acknowledgement sent from the VCN Manager to the Group Agentin step 2320 contains all of the member information required so theGroup Agent can send the appropriate join requests for each member beingproxied. The following information is in the acknowledgement sent fromthe VCN Manager to the Group Agent: packet version indicating theversion of the header, packet type indicating that it is aacknowledgement, packet length, authentication code, subnet IP address,subnet prefix, public IP address of the Private Route Director (when theGroup Agent also includes a Private Route Director), Private RouteDirector ping flag (1 if PRD responds to pings), the number of membersbeing proxied, the number of permanent connections from proxied membersto other members that the proxy must make, the member record list andthe connect record list. The member record list is a set of records foreach member being proxied. The following information is stored in eachrecord: member password (password SHA1 digest), member's local privateIP address, the length of the member's fully qualified domain name, themember's fully qualified domain name, offset to the VCN name,authentication type (0=preshared 1=certificate), time stamp indicatingwhen the token key was created, token length in bytes, token key (membershared secret with VCN Manager), HA version number, number of HArecords, HA record list and authentication key (generated by server forthe proxy). Each HA record in the HA record list includes a VCN ManagerIP address for the next VCN Manager, a join port for the next VCNManager and a service port for the next VCN Manager in case the currentVCN Manager goes down. The connect record list includes the followingthree fields: proxy member index (zero based index into member list),DNS request length and a DNS request.

[0227] Once the Group Agent joins for all of its members, then any ofits members can receive communication from other members of the VCN orcan initiate communication to other members in the VCN. Members that arebeing proxied by a Group Agent can communicate with other members beingproxied by the Group Agent, with other members proxied by a differentGroup Agent (regardless of whether they are in a private network oravailable on the public Internet), and members that do not use a GroupAgent (regardless of whether those other members are in a privatenetwork or available on the Internet with a public IP address), as longas they are all members of the same VCN. From the point of view of anapplication on a member being proxied by the Group Agent, the VCNappears as a local subnet (or LAN) and all of the members of the VCNappear to be on the local subnet (or LAN). However, the VCN is not alocal subnet (or LAN); rather it is a virtual subnet (or LAN). Each ofthe members of the VCN will have a Virtual IP Address on the virtualsubnet.

[0228] Because members of a VCN register with the VCN Manager, the VCNManager will know how to find the members (e.g. it will know its publicand private addresses). Thus, a Group Agent acting as a proxy for afirst member will be able to act as an intermediary for that firstmember when talking to a second member of a VCN even if the secondmember moves to a different or new private network and/or changes its IPaddress. That is, when the second member makes the move or change, thesecond member will so inform the VCN Manager. The VCN Manager willinform the Group Agent of the change so that the Group Agent cancontinue to act as an intermediary between the first member and thegroup member. More information about communicating with mobile entitiescan be found in U.S. patent application Ser. No. 10/233,289, “AccessingAn Entity Inside a Private Network,” filed on Aug. 30, 2002; U.S. patentapplication Ser. No. 10/161,573, “Creating A Public Identity For AnEntity On A Network,” filed on Jun. 3, 2002; and U.S. patent applicationSer. No. 10/233,288, “Communicating With An Entity Inside A PrivateNetwork Using An Existing Connection To Initiate Communication,” filedon Aug. 30, 2002, all three applications are incorporated herein byreference in their entirety.

[0229]FIG. 24 is a flowchart describing one embodiment of a process forinitiating communication with a member that is being proxied by a GroupAgent. In FIG. 24, the communication is being initiated by a member thatis not being proxied by a Group Agent. That is, the member initiatingcommunication is a member that has agent software loaded on it. Thatmember is initiating communication with a member that does not haveagent software. Prior to the process of FIG. 24 being performed, theGroup Agent has joined the member into the VCN and the member initiatingcommunication has already joined the VCN. For example purposes, lookingat FIG. 22, the process of FIG. 24 can be performed by M₅, M₆, M₇, M₈ orM₉ initiating communication with any of devices M₁, M₂, M₃, M₄ or M₁₀.Assume, for example purposes, that device M₉ is initiating communicationwith device M₁. The destination device is also assumed to be served by aPrivate Route Director.

[0230] In step 2402, an application on the source device (e.g., deviceM₉) is intending to send a message to an application on the destinationdevice (e.g., device M₁). In step 2404, the application on the sourcedevice sends a DNS request to the VCN Manager using the domain name ofthe destination. For example, the application on M₉ will send a DNSrequest using the domain name for M₁. In step 2406, the VCN Managerreturns a response to the DNS request. This response includes the publicIP address for private Route Director 2204, the private IP address formember M₁ and the virtual IP address for member M₁. In some embodiments,the DNS response also includes a token key (as described above). TheAgent on the source device (e.g., M₉) stores the information it receivedfrom the VCN Manager. In step 2410, the Agent on the source devicereturns the virtual IP address for the destination to the applicationwhich initiated the DNS request. In step 2412, the application on thesource device initiates the sending of a message to M₁ using the virtualIP address. That is, a virtual IP packet is created where the sourceaddress is the virtual IP address for the source machine (M₉) and thedestination address in the virtual IP packet is the virtual IP addressfor the destination device (device M₁). The virtual IP packet is createdin step 2414 and subject to IPsec (or other security means). In step2416, the virtual IP packet is encapsulated. Encapsulation includesadding a shim, a UDP header and an IP header, all as described above.The shim includes the public IP address for the Private Route Directorassociated with the destination member (e.g., PRD 2204) and the privateIP address for destination (e.g. member M₁). If the source, the memberinitiating communication was in a private network, then the shim wouldalso include the public IP address for the Route Director associatedwith the source and the private IP address for the source. In step 2418,the encapsulated packet is sent to the NAT for the destination's privatenetwork. That is, in the example above, the newly created packet is sentto NAT 2202 via the Internet (or other network). In step 2420, theencapsulated packet is sent from the NAT (e.g., NAT 2202) to the RouteDirector for the destination (e.g., PRD 2204).

[0231] In step 2422 of FIG. 24, the Route Director removes the virtualIP packet and the shim from the encapsulation and presents both thevirtual IP address and the shim to the Group Agent (e.g., Group Agent2204). The Group Agent stores the information from the shim, asdescribed above with respect to the member agent software. In oneembodiment, the Group Agent includes the necessary logic to received thecommunication so that no route director is necessary. In step 2426, theGroup Agent extracts the virtual IP packet from IPsec. In step 2428, theGroup Agent chooses a private IP address for the source entity. In theabove example, the source entity is device M₉. Group Agent 2204 willpick a private IP address that is routable in the private networkassociated with device M₁ and NAT 2202. This private address will beused by device M₁ to identify M₉. In step 2430, the Group Agent willchange the source address in the virtual packet. That is, the virtualpacket originally had a source address equal to the virtual IP addressfor the source device (e.g., M₉) and a destination address equal to thevirtual IP address for the destination device (e.g., M₁). In step 2430,the source address in the virtual IP packet is changed to be equal tothe private IP address chosen by the Group Agent for M₉ in step 2428. Instep 2432, the Group Agent changes the destination address in thevirtual IP packet to be equal to the private IP address in the local LANfor M₁. In step 2434, the packet is sent by the Group Agent to thedestination machine (e.g., sent to M₁).

[0232] The above discussion of FIG. 24 was made with respect to theexample that the communication has been initiated by device M₉ which isa member having a public IP address and member agent software. Theprocess of FIG. 24 can also be performed by a member which does not havea public IP address, including members using a Private Route Directorand/or a Network Route Director. When the process of FIG. 24 is beingperformed by members using Route Directors, the shim that is added tothe encapsulated packet in step 2416 includes the private IP address forthe member and the public IP address for the Route Director. The exampleused in discussing FIG. 24 also assumes that the destination was adevice in a private network where the private network included a GroupAgent and a Private Route Director. The process of FIG. 24 can also beadapted to work with a member using a Group Agent where the member has apublic IP address and/or a member in a private network that uses aNetwork Route Director.

[0233] When sending communication to an entity with a public IP addressthat uses a Group Agent, the shim will include the public IP address forthe Group Agent and the public IP address for the member in step 2416.The packet will not be sent to a NAT or to a Route Director. Rather, thepacket will be sent directly to the Group Agent. The Group Agent willaccess the virtual IP packet in step 2426. Rather than choosing aprivate IP address to identify the source, the Group Agent will choose apublic IP address for the destination to use to refer to the source. Thevirtual IP packet will be changed so that the source address is equal tothe public IP address chosen by the Group Agent to represent the sourceand the destination address will become the public IP address for-thedestination. The virtual IP packet (which is no longer virtual) will besent to the destination.

[0234] If the destination member participates in a VCN using a NetworkRoute Director (e.g., device M₃ using NRD 520), then the encapsulatedpacket is sent to the Network Route Director in step 2418. The NetworkRoute Director will communicate the shim and virtual IP packet to theGroup Agent (e.g., Group Agent 2212) via a persistent connection asdescribed above in FIG. 7, steps 673-675, 677, except that the packet isforwarded to the Group Agent rather than the NAT device. The Group Agentwill then perform steps 2424-2434, as described above.

[0235]FIG. 25 is a flowchart describing one embodiment of a process forthe destination device responding to the initiation of communicationfrom the source device. In the example discussed above, this processwould include device M₁ responding to device M₉. In step 2502, theapplication on device M₁ attempts to send a communication. A packet isthen created using the private addresses. The packet would include asource address equal to the private IP address in the LAN for device M₁.The destination address would be equal to the private IP address in theLAN that is used to identify device M₉. That packet is sent to the GroupAgent in step 2504. In step 2506, the Group Agent changes the packet byreplacing the private addresses with virtual addresses. The sourceaddress is replaced with the virtual IP address in the VCN used toidentify device M₁. The destination address in the packet is replacedwith the virtual IP address in the VCN used to identify device M₉. Instep 2508, this packet is subject to IPsec, and encapsulated asdescribed above.

[0236] In step 2512 of FIG. 25, the Group Agent sends the packet. In theexample above, the Group Agent would send the encapsulated packet todevice M₉ using the public IP address for device M₉. If the Group Agentis sending the packet to a member that is in a private network, then theencapsulated packet would be sent to the Group Agent/Private RouteDirector for the member or to the Network Route Director for thatmember. If the responding device (e.g. M₁) is using a Network RouteDirector, then the Group Agent can still send the reply packet directlyto the original source without going through the Network Route Director.If the replying device (e.g. M₁) has a public IP address, then thepacket sent to the Group Agent would include the public IP addresses forthe responding device and the public IP address that the Group Agenttold the replying device to use to identify the original source device.In one embodiment, when the member using the Group Agent has a public IPaddress, an IPsec tunnel can be created between the Group Agent and themember device.

[0237]FIG. 24 contemplates communication being initiated by a devicethat has member software loaded on it. FIG. 26, on the other hand,describes a process that is performed when communication is initiated bya device that does not have member software and, therefore, uses GroupAgent software. In step 2602, the application on the initiating memberwill send a DNS request. This DNS request will be sent to the GroupAgent. The Group Agent receives the DNS request in step 2604. In step2606, the Group Agent sends its own DNS request for the same domain nameto the VCN Manager. In step 2608, the Group Agent receives a responsefrom the VCN Manager. This response will include the virtual IP addressfor the target, the public IP address of the Route Director for thetarget (if any) and the private IP address for the target (if any). Ifthe target has a public IP address, then the public IP address will bereturned. In step 2610, the Group Agent will choose a private IP addressin the local LAN to be used to identify the target. The virtual IPaddress returned from the DNS request will be mapped to this private IPaddress in the local LAN. In step 2612, the Group Agent will return thatchosen private IP address to the application as a response to theapplication's DNS response. In step 2614, the application will initiatethe communication. In one embodiment, the process of 2614 includesperforming the steps of FIG. 25. Note that if the member who isinitiating the communication in the process of FIG. 26 has a public IPaddress, rather than being in a private network, then in step 2610 theGroup Agent will map the virtual IP address to a public IP address thatthe Group Agent and member will use to identify the target. It is thismapped public IP address that is returned to the application in responseto the DNS request. The mapped public IP address is routable to theGroup Agent.

[0238] Although the Group Agent is described above with respect to usewith a VCN, the technology of the Group Agent is broader than a VCN.Thus, the Group Agent can be used to allow entities to participate inother types of networks, communities, groups, organizations,communications, etc.

[0239] Note that in one embodiment, the member being serviced by theGroup Agent must be in the same physical address realm as the GroupAgent. In this manner, the Group Agent is used to bridge that physicaladdress realm with the virtual space. The Group Agent contains thefunctionality to allow the member to participate in the virtualcommunity; however, all the protocols of the virtual community terminateat the Group Agent. This way, the member receives a normal IP packet.From the point of view of the member, the Group Agent works like arouter which connects the member to the subnet of virtual nodes.

[0240] The foregoing detailed description of the invention has beenpresented for purposes of illustration and description. It is notintended to be exhaustive or to limit the invention to the precise formdisclosed. Many modifications and variations are possible in light ofthe above teaching. For example, any number of VCN Managers may be used.Any combination of NRDs and PRDs may be used to improve networkefficiency. Any combination of Member Agents and Group Agents may beused, and the Virtual Community may be of any size. Additionally, whilethe above description provided an example using the protocols andaddressing currently used on the Internet, the present invention can beused with other protocols and addressing schemes. The describedembodiments were chosen in order to best explain the principles of theinvention and its practical application to thereby enable others skilledin the art to best utilize the invention in various embodiments and withvarious modifications as are suited to the particular use contemplated.It is intended that the scope of the invention be defined by the claimsappended hereto.

We claim:
 1. A virtual community network system, comprising: a virtualnetwork manager including at least one virtual community definitioncomprising at least a domain name and a user set; and at least one routedirector capable of communicating with users in the user set.
 2. Thesystem of claim 1 wherein each user communicates with the virtualnetwork manager and other users in the user set via at least one agent.3. The system of claim 2 wherein the agent is installed on a processingdevice.
 4. The system of claim 2 wherein the agent is installed on aproxy device.
 5. The system of claim 2 wherein the virtual networkmanager includes a NAT device detector for agents installed on aprocessing device behind a NAT device.
 6. The system of claim 1 whereinthe manager comprises a device coupled to a public network and having apublic network address.
 7. The system of claim 1 wherein the user setincludes at least a first user and a second user, said first useraccesses other users in the community using at least a first processingdevice, said second user accesses other users in the community using atleast a second processing device.
 8. The system of claim 7 wherein eachsaid device includes at least one virtual address in the community andat least one physical address.
 9. The system of claim 8 wherein thephysical address is dynamic.
 10. The system of claim 8 wherein thephysical address is static.
 11. The system of claim 8 wherein thephysical address is private.
 12. The system of claim 8 wherein at leastone of said first device or second device is coupled to a first privatenetwork and accesses a public network via a NAT device.
 13. The systemof claim 12 wherein the physical address is dynamic.
 14. The system ofclaim 12 wherein the physical address is static.
 15. The system of claim12 wherein said first device is coupled to said first private network,and said second device is coupled to a second private network andaccesses the public network via a second NAT device.
 16. The system ofclaim 15 wherein said second device includes at least one virtualaddress in the realm and at least one private physical address.
 17. Thesystem of claim 15 wherein the physical address is dynamic.
 18. Thesystem of claim 15 wherein the physical address is static.
 19. Thesystem of claim 15 wherein said at least first private network and saidat least second private network share at least one network address. 20.The system of claim 1 wherein the route director includes a pseudoaddress assignment for at least one user in the user set.
 21. The systemof claim 1 wherein the route director includes a translator for virtualaddress information for a virtual user in a private network realm. 22.The system of claim 1 wherein the virtual community manager is coupledto a public network and includes a public network address.
 23. Thesystem of claim 22 wherein the route director is coupled to said publicnetwork and includes a public network address.
 24. The system of claim22 wherein the route director is coupled to a first private network andsaid route director includes a private network address.
 25. The systemof claim 1 wherein communications between users in the user set areencapsulated.
 26. The system of claim 1 wherein communications betweenusers in the user set are encrypted.
 27. The system of claim 26 whereinsaid encryption uses IPSEC.
 28. The system of claim 26 wherein saidencryption uses DES.
 29. The system of claim 26 wherein said encryptionuses triple DES.
 30. The system of claim 1 wherein the manager includesat least a second virtual domain definition.
 31. The system of claim 1further including at least a first public route director and a secondprivate route director.
 32. A system, comprising: a management deviceincluding network interface coupled to a public address realm and havinga public address; a virtual community network traffic router; and routerdata including at least one association of a logical identifier withpublic routing information for a member.
 33. The system of claim 32wherein the network traffic router includes a network interfaceaccessible by a public address in the public address realm.
 34. Thesystem of claim 32 wherein the management device includes a UDP portcapable of receiving virtual community network traffic.
 35. The systemof claim 32 wherein the management device includes a TCP port capable ofcommunicating virtual community network traffic.
 36. The system of claim32 wherein a member accesses a physical network via a processing deviceand the system further includes at least one agent installed on theprocessing device.
 37. The system of claim 36 wherein the processingdevice is coupled to a private physical network behind a NAT device, andthe network traffic router includes a transposer for routing informationin a packet destined for the agent to direct the packet to the NATdevice for the agent.
 38. The system of claim 32 further including atleast one proxy agent on a private physical network communicating with amember and the network traffic router.
 39. The system of claim 38wherein the member accesses other members using a device coupled to aprivate physical network.
 40. The system of claim 32 wherein the managerincludes a member register module.
 41. The system of claim 40 whereinthe manager includes a member join module.
 42. The system of claim 41wherein the join module provides a virtual address to a registeredmember.
 43. The system of claim 41 wherein the manager maintains data onan association between at least one virtual address with at least onemember.
 44. The system of claim 40 wherein the manager includes a DNSserver for the virtual community.
 45. The system of claim 32 furtherincluding a virtual community network communication agent for a device,comprising a virtual network adapter interfacing with the device andapplications on the device to route traffic to members of the virtualcommunity via their virtual address.
 46. The system of claim 45 whereinthe agent includes a domain name routing plugin.
 47. The system of claim45 wherein the agent includes a separate IP stack for each user in theuser set accessing the device.
 48. The system of claim 45 wherein theadapter is a deterministic network enhancer.
 49. The system of claim 45wherein the adapter includes a DNS plugin.
 50. The system of claim 45wherein the adapter includes an IPSEC plugin.
 51. The system of claim 45wherein the adapter includes a domain name routing plugin.
 52. Thesystem of claim 45 wherein the agent includes a community registrationmodule.
 53. A virtual community network system, comprising: a virtualcommunity network manager; a route director; at least a first virtualcommunity agent associated with a first community member; and at least asecond virtual community agent associated with at least a secondcommunity member.
 54. The system of claim 53 wherein the route directoris a network route director, and includes a public network interface andpublic address.
 55. The system of claim 53 wherein the route director isa private route director, and includes a private physical networkaddress interface and a private physical network address.
 56. The systemof claim 53 wherein the first or second virtual community network agentis installed on a device used by a member to access a network.
 57. Thesystem of claim 56 wherein the device is in a private physical network.58. The system of claim 56 wherein the device is coupled to a publicphysical network.
 59. The system of claim 53 wherein the first or secondvirtual community network agent is a proxy agent.
 60. The system ofclaim 53 wherein the first and second members access the virtualcommunity via devices coupled to separate private address physicalrealms.
 61. The system of claim 53 wherein the virtual community networkmanager includes at least a first community definition and a secondcommunity definition.
 62. The system of claim 53 wherein the communitynetwork manager includes a member authenticator.
 63. The system of claim62 wherein the community network manager includes a DNS server providingauthorative responses for DNS queries in the virtual community.
 64. Amethod for providing a secure virtual network, comprising: providing avirtual network manager coupled to a public network; defining a memberset of users entitled to communicate in the virtual network; registeringmembers with the manager; assigning members a virtual address; androuting network traffic between the members in the virtual community.65. The method of claim 64 further including the step of providing usersin said member set with a communication agent.
 66. The method of claim65 wherein said step of providing users with a communication agentincludes providing a proxy agent.
 67. The method of claim 65 whereinsaid step of providing users with a communication agent includesproviding an agent installed on a device used by the member to couple toa network.
 68. The method of claim 65 wherein the step of registeringcomprises authenticating members with the member set.
 69. The method ofclaim 64 wherein the step of defining a member set includes the step ofassigning a domain name for the community.
 70. The method of claim 64wherein the step of defining a member set includes defining at least twomember sets having at least one different member.
 71. The method ofclaim 64 wherein the step of assigning a virtual address includesassigning an IPV4 compliant address.
 72. The method of claim 71 whereinthe step of assigning a virtual address includes assigning anon-routable IPV4 compliant address.
 73. The method of claim 64 whereinthe step of routing network traffic includes routing traffic from afirst member accessing the public network on a first device having apublic address with a second member accessing the public network on asecond device having a different public address.
 74. The method of claim64 wherein the step of routing network traffic includes routing trafficfrom a first member accessing the public network on a first device in aprivate physical network having a private address with a second memberaccessing the public network on a second device having a public address.75. The method of claim 64 wherein the step of routing network trafficincludes routing traffic from a first member accessing the publicnetwork on a device in a private physical network having a first privatephysical address with a second member accessing the public network on adevice in a private physical network having a second private physicaladdress.
 76. The method of claim 75 wherein the first private physicaladdress and the second private physical address are identical.
 77. Themethod of claim 64 further including the step of responding to DNSrequests for members in the virtual network.
 78. The method of claim 64further including the step of responding to joined status requests forregistered members in the virtual network.
 79. The method of claim 64further including applying a group policy to members of the virtualcommunity.
 80. One or more processor readable storage devices havingprocessor readable code embodied on said processor readable storagedevices, said processor readable code for programming one or moreprocessors to perform a method comprising the steps of: managing avirtual community network realm; defining a member set of users entitledto communicate in the virtual community; registering users with thevirtual community; assigning each user a virtual address; and routingnetwork traffic between the users in the virtual community.
 81. One ormore processor readable storage devices as defined in claim 80 furtherincluding code for programming one or more processors to perform a stepof providing users in said member set with a communication agent. 82.One or more processor readable storage devices as defined in claim 81wherein said step of providing users with a communication agent includesproviding a proxy agent.
 83. One or more processor readable storagedevices as defined in claim 80 wherein the step of defining a member setincludes the step of assigning a domain name for the community.
 84. Oneor more processor readable storage devices as defined in claim 80wherein the step of assigning a virtual address includes a non-routableIPV4 compliant address.
 85. One or more processor readable storagedevices as defined in claim 80 wherein the step of routing networktraffic includes routing traffic from a first member accessing thepublic address realm on a first device having a public address with asecond member accessing the public address realm on a second devicehaving a different public address.
 86. One or more processor readablestorage devices as defined in claim 80 wherein the step of routingnetwork traffic includes routing traffic from a first member accessingthe public address realm on a first device in a private physical networkhaving a private address with a second member accessing the publicaddress realm on a second device having a public address.
 87. One ormore processor readable storage devices as defined in claim 80 whereinthe step of routing network traffic includes routing traffic from afirst member accessing the public address realm on a device in a privatephysical network having a first private physical address with a secondmember accessing the public address realm on a device in a privatephysical network having a second private physical address.
 88. One ormore processor readable storage devices as defined in claim 87 whereinthe step of routing network traffic includes routing traffic to thefirst or second member via a NAT device.
 89. One or more processorreadable storage devices as defined in claim 87 wherein the firstprivate physical address and the second private physical address areidentical.
 90. One or more processor readable storage devices as definedin claim 80 wherein the step of routing includes routing encapsulatedtraffic.
 91. One or more processor readable storage devices as definedin claim 80 wherein the step of routing includes routing encryptedtraffic.
 92. One or more processor readable storage devices as definedin claim 80 further including applying a group policy to members of thevirtual community.
 93. A virtual community network system, comprising: avirtual network manager having a network interface coupled to a network,the manager including at least one virtual community definitioncomprising at least a domain name and a user set, the network beingassessable by users in the user set and users outside the user set, themanager exchanging virtual community network information with users inthe user set.
 94. The system of claim 93 wherein the virtual networkmanager includes a member register module.
 95. The system of claim 93wherein the virtual network manager includes a member join module. 96.The system of claim 95 wherein the join module provides a virtualaddress to a registered member.
 97. The system of claim 93 wherein thevirtual network manager maintains data on an association between atleast one virtual address with at least one member.
 98. The system ofclaim 93 wherein the virtual network manager includes a DNS server forthe virtual community.
 99. The system of claim 93 wherein the virtualnetwork manager includes a NAT device detector for users connecting withthe virtual network manager using a processing device behind a NATdevice.
 100. The system of claim 93 wherein the virtual network managerincludes at least a second virtual domain definition.
 101. The system ofclaim 93 wherein the virtual network manager includes at least a firstvirtual community definition and a second virtual community definition.102. The system of claim 93 wherein the virtual network manager includesa member authenticator.
 103. The system of claim 93 wherein the virtualnetwork manager includes a DNS server providing authorative responsesfor DNS queries form users in the virtual community.
 104. The system ofclaim 93 wherein the system further includes at least one route directorcapable of communicating with users in the user set.
 105. The system ofclaim 93 wherein each user communicates with the virtual network managerand other users in the user set via at least one agent.
 106. The systemof claim 93 wherein the user set includes at least a first user and asecond user, said first user accesses other users in the community usingat least a first processing device, said second user accesses otherusers in the community using at least a second processing device,wherein at least one of said first device or second device is coupled toa first private network and accesses a public network via a NAT device.107. The system of claim 106 wherein said first device is coupled tosaid first private network, and said second device is coupled to asecond private network and accesses the public network via a second NATdevice.
 108. The system of claim 93 wherein communications between usersin the user set are encrypted.
 109. The system of claim 108 wherein thevirtual network manager provides a shared secret to users in the userset to establish encrypted communications.